[PATCH] media: i2c: ov8865: remove unnecessary NULL check

2021-04-12 Thread Paul Kocialkowski
The check on mode_index is sufficient to ensure that we have a
valid mode. Remove the explicit mode check similarly to
commit 38a50230292f ("media: i2c: ov5648: remove unnecessary NULL check")

Signed-off-by: Paul Kocialkowski 
---
 drivers/media/i2c/ov8865.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov8865.c b/drivers/media/i2c/ov8865.c
index 9ecf180635ee..4ad85dc4cd1f 100644
--- a/drivers/media/i2c/ov8865.c
+++ b/drivers/media/i2c/ov8865.c
@@ -2691,7 +2691,7 @@ static int ov8865_enum_frame_interval(struct v4l2_subdev 
*subdev,
}
}
 
-   if (mode_index == ARRAY_SIZE(ov8865_modes) || !mode)
+   if (mode_index == ARRAY_SIZE(ov8865_modes))
return -EINVAL;
 
interval_enum->interval = mode->frame_interval;
-- 
2.31.1



Re: linux-next: manual merge of the irqchip tree with the sunxi tree

2021-02-26 Thread Paul Kocialkowski
Hi,

On Thu 18 Feb 21, 15:48, Stephen Rothwell wrote:
> Hi all,
> 
> On Mon, 15 Feb 2021 09:11:24 +1100 Stephen Rothwell  
> wrote:
> >
> > On Mon, 1 Feb 2021 14:42:59 +1100 Stephen Rothwell  
> > wrote:
> > >
> > > Today's linux-next merge of the irqchip tree got a conflict in:
> > > 
> > >   
> > > Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
> > > 
> > > between commit:
> > > 
> > >   752b0aac99c7 ("dt-bindings: irq: sun7i-nmi: Add binding documentation 
> > > for the V3s NMI")
> > > 
> > > from the sunxi tree and commit:
> > > 
> > >   ad6b47cdef76 ("dt-bindings: irq: sun6i-r: Split the binding from 
> > > sun7i-nmi")
> > > 
> > > from the irqchip tree.
> > > 
> > > I fixed it up (I think - see below) and can carry the fix as
> > > necessary. This is now fixed as far as linux-next is concerned, but any
> > > non trivial conflicts should be mentioned to your upstream maintainer
> > > when your tree is submitted for merging.  You may also want to consider
> > > cooperating with the maintainer of the conflicting tree to minimise any
> > > particularly complex conflicts.
> > > 
> > > diff --cc 
> > > Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
> > > index 4fd1e2780026,f34ecc8c7093..
> > > --- 
> > > a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
> > > +++ 
> > > b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
> > > @@@ -25,17 -25,7 +25,10 @@@ properties
> > > - const: allwinner,sun6i-a31-sc-nmi
> > >   deprecated: true
> > > - const: allwinner,sun7i-a20-sc-nmi
> > > -   - items:
> > > -   - const: allwinner,sun8i-a83t-r-intc
> > > -   - const: allwinner,sun6i-a31-r-intc
> > >  +  - items:
> > >  +  - const: allwinner,sun8i-v3s-nmi
> > >  +  - const: allwinner,sun9i-a80-nmi
> > > - const: allwinner,sun9i-a80-nmi
> > > -   - items:
> > > -   - const: allwinner,sun50i-a64-r-intc
> > > -   - const: allwinner,sun6i-a31-r-intc
> > > - items:
> > > - const: allwinner,sun50i-a100-nmi
> > > - const: allwinner,sun9i-a80-nmi  
> > 
> > With the merge window about to open, this is a reminder that this
> > conflict still exists.  It is now between the arm-soc tree and the
> > irqchip tree.
> 
> This is now a conflict between the arm-soc tree and the tip tree.

The resolution looks correct to me!

Cheers,

Paul

-- 
Developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/


Re: [PATCH v1 00/18] Add HANTRO G2/HEVC decoder support for IMX8MQ

2021-02-17 Thread Paul Kocialkowski
Hi Benjamin,

On Wed 17 Feb 21, 09:28, Benjamin Gaignard wrote:
> Le 17/02/2021 à 09:08, Greg KH a écrit :
> > On Wed, Feb 17, 2021 at 09:02:48AM +0100, Benjamin Gaignard wrote:
> > > The IMX8MQ got two VPUs but until now only G1 has been enabled.
> > > This series aim to add the second VPU (aka G2) and provide basic
> > > HEVC decoding support.
> > Why are you adding this directly to drivers/staging/media/ and not
> > drivers/media/?  Why can't this just go to the main location and not
> > live in staging?
> 
> G2/HEVC is added inside the already exiting Hantro driver, it is "just"
> an other codec from Hantro driver point of view.
> In addition of that v4l2-hevc uAPI is still unstable.
> One goal of this series is to have one more consumer of this v4l2-hevc
> uAPI so maybe we can claim it to be stable enough to move away from staging
> and then do the same for Hantro driver. That would be a great achievement !

Thanks for working on Hantro G2 support!

As the initial author of the HEVC API, it definitely does not feel ready to
be destaged. The API has lots of issues and limitation and I think significant
work is still needed.

This initial implementation was kind of a proof of concept for simple cases.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: BOG: commit 89c7cb1608ac3 ("of/device: Update dma_range_map only when dev has valid dma-ranges") seems to break Pinephone display or LCDC

2021-02-05 Thread Paul Kocialkowski
Hey,

On Tue 02 Feb 21, 16:07, H. Nikolaus Schaller wrote:
> Hi Paul,
> 
> > Am 02.02.2021 um 14:42 schrieb Paul Kocialkowski 
> > :
> > 
> > Hi Nikolaus,
> > 
> > On Tue 02 Feb 21, 11:50, H. Nikolaus Schaller wrote:
> >> Hi Paul,
> >> 
> >>> Am 02.02.2021 um 10:56 schrieb Paul Kocialkowski 
> >>> :
> >>> 
> >>> Hi Nikolaus,
> >>> 
> >>> On Tue 02 Feb 21, 10:18, H. Nikolaus Schaller wrote:
> >>>> Hi,
> >>>> since v5.11-rc6 my Pinephone display shows some moiré pattern.
> >>>> 
> >>>> I did a bisect between v5.11-rc5 and v5.11-rc6 and it told me that
> >>>> the commit mentioned in the subject is the reason.
> >>>> 
> >>>> Reverting it makes the display work again and re-reverting fail again.
> >>>> 
> >>>> IMHO it seems as if the display DMA of the pinephone (allwinner suni-a54)
> >>>> got influenced and stopped to scan the framebuffer.
> >>>> 
> >>>> The only dma-ranges I could find are defined here:
> >>>> 
> >>>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >>>> 
> >>>>  dma-ranges = <0x 0x4000 0xc000>;
> >>>> 
> >>>> but I can't tell if they are "valid" or not.
> >>>> 
> >>>> Any insights are welcome. And please direct to the right people/mailing 
> >>>> lists
> >>>> if they are missing.
> >>> 
> >>> This may not be strictly the same thing, but is this patch in your tree:
> >>> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210115175831.1184260-2-paul.kocialkow...@bootlin.com/
> >>> 
> >>> If not, it's worth a try to add it.
> >> 
> >> No, it hasn't arrived in v5.11-rc6 (or linux-next) yet.
> >> 
> >> But it fixes the issue.
> > 
> > Great! The patch should already be on its way to the next RC.
> 
> Fine!
> 
> > 
> > And nice to see you're active on Pinephone as well!
> 
> I have a developer unit and the LetuxOS kernel already supports it a little. 
> This is why I observed the issue with -rc6
> 
> > You might remember me from
> > the Replicant project, as I've worked a bit on the GTA04 :)
> 
> Sure, you are well remembered :)
> 
> I still have the dream to revitalize Replicant 4.2 for the GTA04 just for 
> fun. I can already boot to Replicant touch screen with a v5.4 kernel. v5.10 
> fails when trying to spawn zygote...

Oh I see! I think Android has made some significant progress is its ability
to use mainline (4.2 was an early stage and I remember having to backport
patches to use some mainline features back then).

Maybe it would be easier with Replicant 6, but you'd have to go through the
device bringup phase again, which is never nice.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: BOG: commit 89c7cb1608ac3 ("of/device: Update dma_range_map only when dev has valid dma-ranges") seems to break Pinephone display or LCDC

2021-02-02 Thread Paul Kocialkowski
Hi Nikolaus,

On Tue 02 Feb 21, 11:50, H. Nikolaus Schaller wrote:
> Hi Paul,
> 
> > Am 02.02.2021 um 10:56 schrieb Paul Kocialkowski 
> > :
> > 
> > Hi Nikolaus,
> > 
> > On Tue 02 Feb 21, 10:18, H. Nikolaus Schaller wrote:
> >> Hi,
> >> since v5.11-rc6 my Pinephone display shows some moiré pattern.
> >> 
> >> I did a bisect between v5.11-rc5 and v5.11-rc6 and it told me that
> >> the commit mentioned in the subject is the reason.
> >> 
> >> Reverting it makes the display work again and re-reverting fail again.
> >> 
> >> IMHO it seems as if the display DMA of the pinephone (allwinner suni-a54)
> >> got influenced and stopped to scan the framebuffer.
> >> 
> >> The only dma-ranges I could find are defined here:
> >> 
> >>arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> 
> >>dma-ranges = <0x 0x4000 0xc000>;
> >> 
> >> but I can't tell if they are "valid" or not.
> >> 
> >> Any insights are welcome. And please direct to the right people/mailing 
> >> lists
> >> if they are missing.
> > 
> > This may not be strictly the same thing, but is this patch in your tree:
> > https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210115175831.1184260-2-paul.kocialkow...@bootlin.com/
> > 
> > If not, it's worth a try to add it.
> 
> No, it hasn't arrived in v5.11-rc6 (or linux-next) yet.
> 
> But it fixes the issue.

Great! The patch should already be on its way to the next RC.

And nice to see you're active on Pinephone as well! You might remember me from
the Replicant project, as I've worked a bit on the GTA04 :)

> great and many thanks,
> Nikolaus

Cheers,

Paul

> > If it is, it's worth doing a revert.
> > 
> > My understanding is like DE2 does not need a particular DMA range and has 
> > DRAM
> > starting at 0x4000 (just like the CPU) but it will map DRAM in a loop
> > before and after this address.
> > 
> > I suspect the issue shows because the pinephone has 2 GiB RAM while for 
> > other
> > boards with < 2 GiB RAM, removing 0x4000 to the DMA addresses still 
> > points
> > to the same location. So IMO the MBUS dma-ranges shouldn't apply to DE2.
> > I think this is already the case in dt, but the mbus driver may add it if 
> > you
> > don't have that patch.
> > 
> > I think I have a few A64 boards around, but probably not with 2 GiB RAM.
> > If adding the patch doesn't help, I'll try to make a few test.
> > 
> > Cheers!
> > 
> > Paul
> > 
> > -- 
> > Paul Kocialkowski, Bootlin
> > Embedded Linux and kernel engineering
> > https://bootlin.com
> 

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: BOG: commit 89c7cb1608ac3 ("of/device: Update dma_range_map only when dev has valid dma-ranges") seems to break Pinephone display or LCDC

2021-02-02 Thread Paul Kocialkowski
Hi Nikolaus,

On Tue 02 Feb 21, 10:18, H. Nikolaus Schaller wrote:
> Hi,
> since v5.11-rc6 my Pinephone display shows some moiré pattern.
> 
> I did a bisect between v5.11-rc5 and v5.11-rc6 and it told me that
> the commit mentioned in the subject is the reason.
> 
> Reverting it makes the display work again and re-reverting fail again.
> 
> IMHO it seems as if the display DMA of the pinephone (allwinner suni-a54)
> got influenced and stopped to scan the framebuffer.
> 
> The only dma-ranges I could find are defined here:
> 
>   arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> 
>   dma-ranges = <0x 0x4000 0xc000>;
> 
> but I can't tell if they are "valid" or not.
> 
> Any insights are welcome. And please direct to the right people/mailing lists
> if they are missing.

This may not be strictly the same thing, but is this patch in your tree:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210115175831.1184260-2-paul.kocialkow...@bootlin.com/

If not, it's worth a try to add it. If it is, it's worth doing a revert.

My understanding is like DE2 does not need a particular DMA range and has DRAM
starting at 0x4000 (just like the CPU) but it will map DRAM in a loop
before and after this address.

I suspect the issue shows because the pinephone has 2 GiB RAM while for other
boards with < 2 GiB RAM, removing 0x4000 to the DMA addresses still points
to the same location. So IMO the MBUS dma-ranges shouldn't apply to DE2.
I think this is already the case in dt, but the mbus driver may add it if you
don't have that patch.

I think I have a few A64 boards around, but probably not with 2 GiB RAM.
If adding the patch doesn't help, I'll try to make a few test.

Cheers!

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH 2/2] soc: sunxi: mbus: Remove DE2 display engine compatibles

2021-01-27 Thread Paul Kocialkowski
Hi,

On Fri 15 Jan 21, 18:58, Paul Kocialkowski wrote:
> The DE2 display engine hardware takes physical addresses that do not
> need PHYS_BASE subtracted. As a result, they should not be present
> on the mbus driver match list. Remove them.
> 
> This was tested on the A83T, along with the patch allowing the DMA
> range map to be non-NULL and restores a working display.

Could we get this merged ASAP (in this RC cycle), hopefully with the patch
that superseded 1/2 from this series so that we don't end up with either
CSI or DE2 broken in the next release?

Cheers,

Paul

> Fixes: b4bdc4fbf8d0 ("soc: sunxi: Deal with the MBUS DMA offsets in a central 
> place")
> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/soc/sunxi/sunxi_mbus.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/drivers/soc/sunxi/sunxi_mbus.c b/drivers/soc/sunxi/sunxi_mbus.c
> index e9925c8487d7..d90e4a264b6f 100644
> --- a/drivers/soc/sunxi/sunxi_mbus.c
> +++ b/drivers/soc/sunxi/sunxi_mbus.c
> @@ -23,12 +23,7 @@ static const char * const sunxi_mbus_devices[] = {
>   "allwinner,sun7i-a20-display-engine",
>   "allwinner,sun8i-a23-display-engine",
>   "allwinner,sun8i-a33-display-engine",
> - "allwinner,sun8i-a83t-display-engine",
> - "allwinner,sun8i-h3-display-engine",
> - "allwinner,sun8i-r40-display-engine",
> - "allwinner,sun8i-v3s-display-engine",
>   "allwinner,sun9i-a80-display-engine",
> - "allwinner,sun50i-a64-display-engine",
>  
>   /*
>* And now we have the regular devices connected to the MBUS
> -- 
> 2.30.0
> 

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH 1/2] of: device: Allow DMA range map to be set before of_dma_configure_id

2021-01-27 Thread Paul Kocialkowski
Hi,

On Fri 15 Jan 21, 18:58, Paul Kocialkowski wrote:
> A mechanism was recently introduced for the sunxi architecture where
> the DMA offset for specific devices (under the MBUS) is set by a common
> driver (sunxi_mbus). This driver calls dma_direct_set_offset to set
> the device's dma_range_map manually.
> 
> However this information was overwritten by of_dma_configure_id, which
> obtains the map from of_dma_get_range (or keeps it NULL when it fails
> and the force_dma argument is true, which is the case for platform
> devices).
> 
> As a result, the dma_range_map was always overwritten and the mechanism
> could not correctly take effect.
> 
> This adds a check to ensure that no previous DMA range map is
> overwritten and prints a warning when the map was already set while
> also being available from dt. In this case, the map that was already
> set is kept.

FYI this patch has been superseded by the following:
https://patchwork.kernel.org/project/linux-mediatek/patch/20210119105203.15530-1-yong...@mediatek.com/

Paul

> Fixes: b4bdc4fbf8d0 ("soc: sunxi: Deal with the MBUS DMA offsets in a central 
> place")
> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/of/device.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index aedfaaafd3e7..db1b8634c2c7 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -181,7 +181,14 @@ int of_dma_configure_id(struct device *dev, struct 
> device_node *np,
>  
>   arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
>  
> - dev->dma_range_map = map;
> + if (!dev->dma_range_map) {
> + dev->dma_range_map = map;
> + } else if (map) {
> + dev_warn(dev,
> +  "DMA range map was already set, ignoring range map 
> from dt\n");
> + kfree(map);
> + }
> +
>   return 0;
>  }
>  EXPORT_SYMBOL_GPL(of_dma_configure_id);
> -- 
> 2.30.0
> 

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH v2] of/device: Update dma_range_map only when dev has valid dma-ranges

2021-01-27 Thread Paul Kocialkowski
Hi,

On Tue 19 Jan 21, 18:52, Yong Wu wrote:
> The commit e0d072782c73 ("dma-mapping: introduce DMA range map,
> supplanting dma_pfn_offset") always update dma_range_map even though it was
> already set, like in the sunxi_mbus driver. the issue is reported at [1].
> This patch avoid this(Updating it only when dev has valid dma-ranges).
> 
> Meanwhile, dma_range_map contains the devices' dma_ranges information,
> This patch moves dma_range_map before of_iommu_configure. The iommu
> driver may need to know the dma_address requirements of its iommu
> consumer devices.

Just a gentle ping on this issue, it would be nice to have this fix merged
ASAP, in the next RC :)

Cheers,

Paul

> [1] 
> https://lore.kernel.org/linux-arm-kernel/5c7946f3-b56e-da00-a750-be097c7ce...@arm.com/
> 
> CC: Rob Herring 
> CC: Frank Rowand 
> Fixes: e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting 
> dma_pfn_offset"),
> Suggested-by: Robin Murphy 
> Signed-off-by: Yong Wu 
> Signed-off-by: Paul Kocialkowski 
> Reviewed-by: Rob Herring 
> ---
>  drivers/of/device.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index aedfaaafd3e7..1122daa8e273 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -162,9 +162,11 @@ int of_dma_configure_id(struct device *dev, struct 
> device_node *np,
>   mask = DMA_BIT_MASK(ilog2(end) + 1);
>   dev->coherent_dma_mask &= mask;
>   *dev->dma_mask &= mask;
> - /* ...but only set bus limit if we found valid dma-ranges earlier */
> - if (!ret)
> + /* ...but only set bus limit and range map if we found valid dma-ranges 
> earlier */
> + if (!ret) {
>   dev->bus_dma_limit = end;
> + dev->dma_range_map = map;
> + }
>  
>   coherent = of_dma_is_coherent(np);
>   dev_dbg(dev, "device is%sdma coherent\n",
> @@ -172,6 +174,9 @@ int of_dma_configure_id(struct device *dev, struct 
> device_node *np,
>  
>   iommu = of_iommu_configure(dev, np, id);
>   if (PTR_ERR(iommu) == -EPROBE_DEFER) {
> + /* Don't touch range map if it wasn't set from a valid 
> dma-ranges */
> + if (!ret)
> + dev->dma_range_map = NULL;
>   kfree(map);
>   return -EPROBE_DEFER;
>   }
> @@ -181,7 +186,6 @@ int of_dma_configure_id(struct device *dev, struct 
> device_node *np,
>  
>   arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
>  
> - dev->dma_range_map = map;
>   return 0;
>  }
>  EXPORT_SYMBOL_GPL(of_dma_configure_id);
> -- 
> 2.18.0
> 

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH v6 06/33] of/device: Move dma_range_map before of_iommu_configure

2021-01-19 Thread Paul Kocialkowski
Hi,

On Tue 19 Jan 21, 17:20, Yong Wu wrote:
> On Mon, 2021-01-18 at 15:49 +, Robin Murphy wrote:
> > On 2021-01-15 05:30, Yong Wu wrote:
> > > On Thu, 2021-01-14 at 13:27 -0600, Rob Herring wrote:
> > >> On Mon, Jan 11, 2021 at 07:18:47PM +0800, Yong Wu wrote:
> > >>> "dev->dma_range_map" contains the devices' dma_ranges information,
> > >>> This patch moves dma_range_map before of_iommu_configure. The iommu
> > >>> driver may need to know the dma_address requirements of its iommu
> > >>> consumer devices.
> > >>>
> > >>> CC: Rob Herring 
> > >>> CC: Frank Rowand 
> > >>> Signed-off-by: Yong Wu 
> > >>> ---
> > >>>   drivers/of/device.c | 3 ++-
> > >>>   1 file changed, 2 insertions(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/drivers/of/device.c b/drivers/of/device.c
> > >>> index aedfaaafd3e7..1d84636149df 100644
> > >>> --- a/drivers/of/device.c
> > >>> +++ b/drivers/of/device.c
> > >>> @@ -170,9 +170,11 @@ int of_dma_configure_id(struct device *dev, struct 
> > >>> device_node *np,
> > >>> dev_dbg(dev, "device is%sdma coherent\n",
> > >>> coherent ? " " : " not ");
> > >>>   
> > >>> +   dev->dma_range_map = map;
> > >>> iommu = of_iommu_configure(dev, np, id);
> > >>> if (PTR_ERR(iommu) == -EPROBE_DEFER) {
> > >>> kfree(map);
> > >>> +   dev->dma_range_map = NULL;
> > >>
> > >> Not really going to matter, but you should probably clear dma_range_map
> > >> before what it points to is freed.
> > >>
> > >> With that,
> > >>
> > >> Reviewed-by: Rob Herring 
> > > 
> > > Thanks for the review. I will move it before "kfree(map)" in next
> > > version.
> > 
> > Paul noticed that we already have a bug in assigning to this 
> > unconditionally[1] - I'd totally forgotten about this series when I 
> > theorised about IOMMU drivers wanting the information earlier, but 
> > sweeping my inbox now only goes to show I was right to think of it :)
> > 
> > We should really get something in as a fix independent of this series, 
> > taking both angles into account.
> 
> Thanks this info. Following your suggestion, Move this into the "if (!
> ret)". Then it is like this:

Thanks for preparing the change :)

> 
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -163,8 +163,10 @@ int of_dma_configure_id(struct device *dev, struct
> device_node *np,
>   dev->coherent_dma_mask &= mask;
>   *dev->dma_mask &= mask;
>   /* ...but only set bus limit if we found valid dma-ranges earlier */

Maybe the comment would need some update too, like:
/* ...but only set bus limit and map if we found valid dma-ranges earlier */

> - if (!ret)
> + if (!ret) {
>   dev->bus_dma_limit = end;
> + dev->dma_range_map = map;
> + }
>  
>   coherent = of_dma_is_coherent(np);
>   dev_dbg(dev, "device is%sdma coherent\n",
> @@ -172,6 +174,8 @@ int of_dma_configure_id(struct device *dev, struct
> device_node *np,
>  
>   iommu = of_iommu_configure(dev, np, id);
>   if (PTR_ERR(iommu) == -EPROBE_DEFER) {

And maybe one here, something like:
/* don't touch range map if it wasn't set from a valid dma-ranges */

> + if (!ret)
> + dev->dma_range_map = NULL;
>   kfree(map);
>   return -EPROBE_DEFER;
>   }
> @@ -181,7 +185,6 @@ int of_dma_configure_id(struct device *dev, struct
> device_node *np,
>  
>   arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
>  
> - dev->dma_range_map = map;
>   return 0;
>  }
>  EXPORT_SYMBOL_GPL(of_dma_configure_id);
> 
> 
> If this is ok, I will send this as a independent patch.

With the suggested changes, this looks good to me!

Thanks,

Paul

> > 
> > Robin.
> > 
> > [1] 
> > https://lore.kernel.org/linux-arm-kernel/5c7946f3-b56e-da00-a750-be097c7ce...@arm.com/
> > 
> > >>
> > >>> return -EPROBE_DEFER;
> > >>> }
> > >>>   
> > >>> @@ -181,7 +183,6 @@ int of_dma_configure_id(struct device *dev, struct 
> > >>> device_node *np,
> > >>>   
> > >>> arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
> > >>>   
> > >>> -   dev->dma_range_map = map;
> > >>> return 0;
> > >>>   }
> > >>>   EXPORT_SYMBOL_GPL(of_dma_configure_id);
> > >>> -- 
> > >>> 2.18.0
> > >>>
> > > 
> > > ___
> > > iommu mailing list
> > > io...@lists.linux-foundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/iommu
> > > 
> 

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH v6 06/33] of/device: Move dma_range_map before of_iommu_configure

2021-01-19 Thread Paul Kocialkowski
Hi,

On Mon 18 Jan 21, 15:49, Robin Murphy wrote:
> On 2021-01-15 05:30, Yong Wu wrote:
> > On Thu, 2021-01-14 at 13:27 -0600, Rob Herring wrote:
> > > On Mon, Jan 11, 2021 at 07:18:47PM +0800, Yong Wu wrote:
> > > > "dev->dma_range_map" contains the devices' dma_ranges information,
> > > > This patch moves dma_range_map before of_iommu_configure. The iommu
> > > > driver may need to know the dma_address requirements of its iommu
> > > > consumer devices.
> > > > 
> > > > CC: Rob Herring 
> > > > CC: Frank Rowand 
> > > > Signed-off-by: Yong Wu 
> > > > ---
> > > >   drivers/of/device.c | 3 ++-
> > > >   1 file changed, 2 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/of/device.c b/drivers/of/device.c
> > > > index aedfaaafd3e7..1d84636149df 100644
> > > > --- a/drivers/of/device.c
> > > > +++ b/drivers/of/device.c
> > > > @@ -170,9 +170,11 @@ int of_dma_configure_id(struct device *dev, struct 
> > > > device_node *np,
> > > > dev_dbg(dev, "device is%sdma coherent\n",
> > > > coherent ? " " : " not ");
> > > > +   dev->dma_range_map = map;
> > > > iommu = of_iommu_configure(dev, np, id);
> > > > if (PTR_ERR(iommu) == -EPROBE_DEFER) {
> > > > kfree(map);
> > > > +   dev->dma_range_map = NULL;
> > > 
> > > Not really going to matter, but you should probably clear dma_range_map
> > > before what it points to is freed.
> > > 
> > > With that,
> > > 
> > > Reviewed-by: Rob Herring 
> > 
> > Thanks for the review. I will move it before "kfree(map)" in next
> > version.
> 
> Paul noticed that we already have a bug in assigning to this
> unconditionally[1] - I'd totally forgotten about this series when I
> theorised about IOMMU drivers wanting the information earlier, but sweeping
> my inbox now only goes to show I was right to think of it :)
> 
> We should really get something in as a fix independent of this series,
> taking both angles into account.

Okay, I can also fix this while fixing my case. So we'd go for setting
dev->dma_range_map = map; under the if (!ret).

Then I think the error case for of_iommu_configure should be to set
dev->dma_range_map = NULL; only if map != NULL (otherwise we'd be overwriting
and leaking the previously-set map).

I think a comment to remind that dev->dma_range_map can be set prior to this
function would be useful too.

What do you think?

Cheers,

Paul

> Robin.
> 
> [1] 
> https://lore.kernel.org/linux-arm-kernel/5c7946f3-b56e-da00-a750-be097c7ce...@arm.com/
> 
> > > 
> > > > return -EPROBE_DEFER;
> > > >     }
> > > > @@ -181,7 +183,6 @@ int of_dma_configure_id(struct device *dev, struct 
> > > > device_node *np,
> > > > arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
> > > > -   dev->dma_range_map = map;
> > > > return 0;
> > > >   }
> > > >   EXPORT_SYMBOL_GPL(of_dma_configure_id);
> > > > -- 
> > > > 2.18.0
> > > > 
> > 
> > ___
> > iommu mailing list
> > io...@lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/iommu
> > 

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH 1/2] of: device: Allow DMA range map to be set before of_dma_configure_id

2021-01-19 Thread Paul Kocialkowski
Hi Robin,

On Mon 18 Jan 21, 13:27, Robin Murphy wrote:
> On 2021-01-16 17:07, Paul Kocialkowski wrote:
> > Hi Robin,
> > 
> > Le Sat 16 Jan 21, 14:57, Robin Murphy a écrit :
> > > On 2021-01-15 17:58, Paul Kocialkowski wrote:
> > > > A mechanism was recently introduced for the sunxi architecture where
> > > > the DMA offset for specific devices (under the MBUS) is set by a common
> > > > driver (sunxi_mbus). This driver calls dma_direct_set_offset to set
> > > > the device's dma_range_map manually.
> > > > 
> > > > However this information was overwritten by of_dma_configure_id, which
> > > > obtains the map from of_dma_get_range (or keeps it NULL when it fails
> > > > and the force_dma argument is true, which is the case for platform
> > > > devices).
> > > > 
> > > > As a result, the dma_range_map was always overwritten and the mechanism
> > > > could not correctly take effect.
> > > > 
> > > > This adds a check to ensure that no previous DMA range map is
> > > > overwritten and prints a warning when the map was already set while
> > > > also being available from dt. In this case, the map that was already
> > > > set is kept.
> > > 
> > > Hang on, the hard-coded offset is only intended to be installed when there
> > > *isn't* anything described in DT, in which case of_dma_get_range() should
> > > always bail out early without touching it anyway. This sounds like
> > > something's not quite right in the MBUS driver, so I don't think working
> > > around it in core code is really the right thing to do.
> > 
> > That's right, there is no practical case where the two are in conflict.
> > The problem that I'm solving here is that dev->dma_range_map is *always*
> > assigned, even when of_dma_get_range bailed and map still is NULL.
> > 
> > This has the effect of always overwriting what the MBUS driver does
> > (and leaking its memory too).
> 
> Oh, I should have looked closer at of_dma_configure_id() itself. I was
> assuming that b4bdc4fbf8d0 had been tested and at least *could* work, but
> apparently not :/
> 
> Indeed it seems there was a fundamental oversight in e0d072782c73
> ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset"),
> equivalent to the same one I previously made myself with bus_dma_mask and
> fixed in 6778be4e5209 ("of/device: Really only set bus DMA mask when
> appropriate"). I think same simpler fix is the right one for this case too,
> i.e. just move the assignment to dev->dma_range_map up under the "if (!ret)"
> condition. Assigning it this late - after the IOMMU and arch setup - looks
> wrong anyway, even if it isn't currently an issue in practice (in principle
> an IOMMU driver *could* start trying to figure out reserved regions around
> DMA windows for a device as early as its .of_xlate callback, even though
> that's not the intent of the API design).

Okay sounds good, I'll resend a patch with the assignment under if (!ret)!

> Luckily dma_range_map hasn't been hooked up in the equivalent ACPI path yet,
> so you're off the hook for fixing that too :)

Good for me :)

Cheers,

Paul

> > > Do you have a case where one of the relevant devices inherits a 
> > > "dma-ranges"
> > > via the regular hierarchy without indirecting via an "interconnects"
> > > reference? Currently you're only checking for the latter, so that would be
> > > one way things could go awry (although to be a problem, said "dma-ranges"
> > > would also have to encode something *other* than the appropriate MBUS
> > > offset, which implies an incorrect or at least inaccurately-structured DT 
> > > as
> > > well).
> > 
> > No, I think things are good in that regard. No messed up dt or anything like
> > that :)
> > 
> > Cheers,
> > 
> > Paul
> > 
> > > Robin.
> > > 
> > > > Fixes: b4bdc4fbf8d0 ("soc: sunxi: Deal with the MBUS DMA offsets in a 
> > > > central place")
> > > > Signed-off-by: Paul Kocialkowski 
> > > > ---
> > > >drivers/of/device.c | 9 -
> > > >1 file changed, 8 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/of/device.c b/drivers/of/device.c
> > > > index aedfaaafd3e7..db1b8634c2c7 100644
> > > > --- a/drivers/of/device.c
> > > > +++ b/drivers/of/device.c
> > > > @@ -181,7 +181,14 @@ int of_dma_configure_id(struct device *dev, struct 
> > > > device_node *np,
> > > > arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
> > > > -   dev->dma_range_map = map;
> > > > +   if (!dev->dma_range_map) {
> > > > +   dev->dma_range_map = map;
> > > > +   } else if (map) {
> > > > +   dev_warn(dev,
> > > > +"DMA range map was already set, ignoring range 
> > > > map from dt\n");
> > > > +   kfree(map);
> > > > +   }
> > > > +
> > > > return 0;
> > > >}
> > > >EXPORT_SYMBOL_GPL(of_dma_configure_id);
> > > > 
> > 

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH] media: i2c: fix odd_ptr_err.cocci warnings

2021-01-18 Thread Paul Kocialkowski
Hi,

On Sat 16 Jan 21, 21:11, Julia Lawall wrote:
> From: kernel test robot 
> 
> PTR_ERR should access the value just tested by IS_ERR

Good catch!

Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci
> 
> Fixes: 11c0d8fdccc5 ("media: i2c: Add support for the OV8865 image sensor")
> CC: Paul Kocialkowski 
> Reported-by: kernel test robot 
> Signed-off-by: kernel test robot 
> Signed-off-by: Julia Lawall 
> ---
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 
> master
> head:   b3a3cbdec55b090d22a09f75efb7c7d34cb97f25
> commit: 11c0d8fdccc56fa15cb15906480b4737c31dd085 [2650/3956] media: i2c: Add 
> support for the OV8865 image sensor
> :: branch date: 2 days ago
> :: commit date: 4 days ago
> 
>  ov8865.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/drivers/media/i2c/ov8865.c
> +++ b/drivers/media/i2c/ov8865.c
> @@ -2849,7 +2849,7 @@ static int ov8865_probe(struct i2c_clien
>   sensor->avdd = devm_regulator_get(dev, "avdd");
>   if (IS_ERR(sensor->avdd)) {
>   dev_err(dev, "cannot get AVDD (analog) regulator\n");
> - ret = PTR_ERR(sensor->dvdd);
> + ret = PTR_ERR(sensor->avdd);
>   goto error_endpoint;
>   }
> 

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH 1/2] of: device: Allow DMA range map to be set before of_dma_configure_id

2021-01-16 Thread Paul Kocialkowski
Hi Robin,

Le Sat 16 Jan 21, 14:57, Robin Murphy a écrit :
> On 2021-01-15 17:58, Paul Kocialkowski wrote:
> > A mechanism was recently introduced for the sunxi architecture where
> > the DMA offset for specific devices (under the MBUS) is set by a common
> > driver (sunxi_mbus). This driver calls dma_direct_set_offset to set
> > the device's dma_range_map manually.
> > 
> > However this information was overwritten by of_dma_configure_id, which
> > obtains the map from of_dma_get_range (or keeps it NULL when it fails
> > and the force_dma argument is true, which is the case for platform
> > devices).
> > 
> > As a result, the dma_range_map was always overwritten and the mechanism
> > could not correctly take effect.
> > 
> > This adds a check to ensure that no previous DMA range map is
> > overwritten and prints a warning when the map was already set while
> > also being available from dt. In this case, the map that was already
> > set is kept.
> 
> Hang on, the hard-coded offset is only intended to be installed when there
> *isn't* anything described in DT, in which case of_dma_get_range() should
> always bail out early without touching it anyway. This sounds like
> something's not quite right in the MBUS driver, so I don't think working
> around it in core code is really the right thing to do.

That's right, there is no practical case where the two are in conflict.
The problem that I'm solving here is that dev->dma_range_map is *always*
assigned, even when of_dma_get_range bailed and map still is NULL.

This has the effect of always overwriting what the MBUS driver does
(and leaking its memory too).

> Do you have a case where one of the relevant devices inherits a "dma-ranges"
> via the regular hierarchy without indirecting via an "interconnects"
> reference? Currently you're only checking for the latter, so that would be
> one way things could go awry (although to be a problem, said "dma-ranges"
> would also have to encode something *other* than the appropriate MBUS
> offset, which implies an incorrect or at least inaccurately-structured DT as
> well).

No, I think things are good in that regard. No messed up dt or anything like
that :)

Cheers,

Paul

> Robin.
> 
> > Fixes: b4bdc4fbf8d0 ("soc: sunxi: Deal with the MBUS DMA offsets in a 
> > central place")
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >   drivers/of/device.c | 9 -
> >   1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/of/device.c b/drivers/of/device.c
> > index aedfaaafd3e7..db1b8634c2c7 100644
> > --- a/drivers/of/device.c
> > +++ b/drivers/of/device.c
> > @@ -181,7 +181,14 @@ int of_dma_configure_id(struct device *dev, struct 
> > device_node *np,
> > arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
> > -   dev->dma_range_map = map;
> > +   if (!dev->dma_range_map) {
> > +   dev->dma_range_map = map;
> > +   } else if (map) {
> > +   dev_warn(dev,
> > +"DMA range map was already set, ignoring range map 
> > from dt\n");
> > +   kfree(map);
> > +   }
> > +
> > return 0;
> >   }
> >   EXPORT_SYMBOL_GPL(of_dma_configure_id);
> > 

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


[PATCH v5 02/16] phy: Distinguish between Rx and Tx for MIPI D-PHY with submodes

2021-01-15 Thread Paul Kocialkowski
As some D-PHY controllers support both Rx and Tx mode, we need a way for
users to explicitly request one or the other. For instance, Rx mode can
be used along with MIPI CSI-2 while Tx mode can be used with MIPI DSI.

Introduce new MIPI D-PHY PHY submodes to use with PHY_MODE_MIPI_DPHY.
The default (zero value) is kept to Tx so only the rkisp1 driver, which
uses D-PHY in Rx mode, needs to be adapted.

Signed-off-by: Paul Kocialkowski 
Acked-by: Helen Koike 
---
 drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c |  3 ++-
 include/linux/phy/phy-mipi-dphy.h   | 13 +
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c 
b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
index 2e5b57e3aedc..cab261644102 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
@@ -948,7 +948,8 @@ static int rkisp1_mipi_csi2_start(struct rkisp1_isp *isp,
 
phy_mipi_dphy_get_default_config(pixel_clock, isp->sink_fmt->bus_width,
 sensor->lanes, cfg);
-   phy_set_mode(sensor->dphy, PHY_MODE_MIPI_DPHY);
+   phy_set_mode_ext(cdev->dphy, PHY_MODE_MIPI_DPHY,
+PHY_MIPI_DPHY_SUBMODE_RX);
phy_configure(sensor->dphy, );
phy_power_on(sensor->dphy);
 
diff --git a/include/linux/phy/phy-mipi-dphy.h 
b/include/linux/phy/phy-mipi-dphy.h
index a877ffee845d..0f57ef46a8b5 100644
--- a/include/linux/phy/phy-mipi-dphy.h
+++ b/include/linux/phy/phy-mipi-dphy.h
@@ -6,6 +6,19 @@
 #ifndef __PHY_MIPI_DPHY_H_
 #define __PHY_MIPI_DPHY_H_
 
+/**
+ * enum phy_mipi_dphy_submode - MIPI D-PHY sub-mode
+ *
+ * A MIPI D-PHY can be used to transmit or receive data.
+ * Since some controllers can support both, the direction to enable is 
specified
+ * with the PHY sub-mode. Transmit is assumed by default with phy_set_mode.
+ */
+
+enum phy_mipi_dphy_submode {
+   PHY_MIPI_DPHY_SUBMODE_TX = 0,
+   PHY_MIPI_DPHY_SUBMODE_RX,
+};
+
 /**
  * struct phy_configure_opts_mipi_dphy - MIPI D-PHY configuration set
  *
-- 
2.30.0



[PATCH v5 13/16] dt-bindings: media: Add A83T MIPI CSI-2 bindings documentation

2021-01-15 Thread Paul Kocialkowski
This introduces YAML bindings documentation for the A83T MIPI CSI-2
controller.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Rob Herring 
---
 .../media/allwinner,sun8i-a83t-mipi-csi2.yaml | 147 ++
 1 file changed, 147 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml

diff --git 
a/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml 
b/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml
new file mode 100644
index ..e607fae7d85e
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml
@@ -0,0 +1,147 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/allwinner,sun8i-a83t-mipi-csi2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A83T MIPI CSI-2 Device Tree Bindings
+
+maintainers:
+  - Paul Kocialkowski 
+
+properties:
+  compatible:
+const: allwinner,sun8i-a83t-mipi-csi2
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+items:
+  - description: Bus Clock
+  - description: Module Clock
+  - description: MIPI-specific Clock
+  - description: Misc CSI Clock
+
+  clock-names:
+items:
+  - const: bus
+  - const: mod
+  - const: mipi
+  - const: misc
+
+  resets:
+maxItems: 1
+
+  # See ./video-interfaces.txt for details
+  ports:
+type: object
+
+properties:
+  port@0:
+type: object
+description: Input port, connect to a MIPI CSI-2 sensor
+
+properties:
+  reg:
+const: 0
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+  clock-lanes:
+maxItems: 1
+
+  data-lanes:
+minItems: 1
+maxItems: 4
+
+required:
+  - data-lanes
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
+  port@1:
+type: object
+description: Output port, connect to a CSI controller
+
+properties:
+  reg:
+const: 1
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+required:
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - resets
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+
+mipi_csi2: csi@1cb1000 {
+compatible = "allwinner,sun8i-a83t-mipi-csi2";
+reg = <0x01cb1000 0x1000>;
+interrupts = ;
+clocks = < CLK_BUS_CSI>,
+ < CLK_CSI_SCLK>,
+ < CLK_MIPI_CSI>,
+ < CLK_CSI_MISC>;
+clock-names = "bus", "mod", "mipi", "misc";
+resets = < RST_BUS_CSI>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+mipi_csi2_in: port@0 {
+reg = <0>;
+
+mipi_csi2_in_ov8865: endpoint {
+data-lanes = <1 2 3 4>;
+
+remote-endpoint = <_out_mipi_csi2>;
+};
+};
+
+mipi_csi2_out: port@1 {
+reg = <1>;
+
+mipi_csi2_out_csi: endpoint {
+remote-endpoint = <_in_mipi_csi2>;
+};
+};
+};
+};
+
+...
-- 
2.30.0



[PATCH v5 10/16] media: sunxi: Add support for the A31 MIPI CSI-2 controller

2021-01-15 Thread Paul Kocialkowski
The A31 MIPI CSI-2 controller is a dedicated MIPI CSI-2 bridge
found on Allwinner SoCs such as the A31 and V3/V3s.

It is a standalone block, connected to the CSI controller on one side
and to the MIPI D-PHY block on the other. It has a dedicated address
space, interrupt line and clock.

It is represented as a V4L2 subdev to the CSI controller and takes a
MIPI CSI-2 sensor as its own subdev, all using the fwnode graph and
media controller API.

Only 8-bit and 10-bit Bayer formats are currently supported.
While up to 4 internal channels to the CSI controller exist, only one
is currently supported by this implementation.

Signed-off-by: Paul Kocialkowski 
Acked-by: Maxime Ripard 
---
 drivers/media/platform/sunxi/Kconfig  |   1 +
 drivers/media/platform/sunxi/Makefile |   1 +
 .../platform/sunxi/sun6i-mipi-csi2/Kconfig|  12 +
 .../platform/sunxi/sun6i-mipi-csi2/Makefile   |   4 +
 .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c   | 600 ++
 .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h   | 117 
 6 files changed, 735 insertions(+)
 create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
 create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
 create mode 100644 
drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
 create mode 100644 
drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h

diff --git a/drivers/media/platform/sunxi/Kconfig 
b/drivers/media/platform/sunxi/Kconfig
index 7151cc249afa..9684e07454ad 100644
--- a/drivers/media/platform/sunxi/Kconfig
+++ b/drivers/media/platform/sunxi/Kconfig
@@ -2,3 +2,4 @@
 
 source "drivers/media/platform/sunxi/sun4i-csi/Kconfig"
 source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
+source "drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig"
diff --git a/drivers/media/platform/sunxi/Makefile 
b/drivers/media/platform/sunxi/Makefile
index fc537c9f5ca9..887a7cae8fca 100644
--- a/drivers/media/platform/sunxi/Makefile
+++ b/drivers/media/platform/sunxi/Makefile
@@ -2,5 +2,6 @@
 
 obj-y  += sun4i-csi/
 obj-y  += sun6i-csi/
+obj-y  += sun6i-mipi-csi2/
 obj-y  += sun8i-di/
 obj-y  += sun8i-rotate/
diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig 
b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
new file mode 100644
index ..47f1bb0779a8
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config VIDEO_SUN6I_MIPI_CSI2
+   tristate "Allwinner A31 MIPI CSI-2 Controller Driver"
+   depends on ARCH_SUNXI || COMPILE_TEST
+   depends on PM && COMMON_CLK && VIDEO_V4L2
+   select REGMAP_MMIO
+   select PHY_SUN6I_MIPI_DPHY
+   select MEDIA_CONTROLLER
+   select VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+   help
+  Support for the Allwinner A31 MIPI CSI-2 Controller.
diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile 
b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
new file mode 100644
index ..14e4e03818b5
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-only
+sun6i-mipi-csi2-y += sun6i_mipi_csi2.o
+
+obj-$(CONFIG_VIDEO_SUN6I_MIPI_CSI2) += sun6i-mipi-csi2.o
diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c 
b/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
new file mode 100644
index ..69186f0c35c2
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
@@ -0,0 +1,600 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 Bootlin
+ * Author: Paul Kocialkowski 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sun6i_mipi_csi2.h"
+
+#define MODULE_NAME"sun6i-mipi-csi2"
+
+static const u32 sun6i_mipi_csi2_mbus_codes[] = {
+   MEDIA_BUS_FMT_SBGGR8_1X8,
+   MEDIA_BUS_FMT_SGBRG8_1X8,
+   MEDIA_BUS_FMT_SGRBG8_1X8,
+   MEDIA_BUS_FMT_SRGGB8_1X8,
+   MEDIA_BUS_FMT_SBGGR10_1X10,
+   MEDIA_BUS_FMT_SGBRG10_1X10,
+   MEDIA_BUS_FMT_SGRBG10_1X10,
+   MEDIA_BUS_FMT_SRGGB10_1X10,
+};
+
+/* Video */
+
+static int sun6i_mipi_csi2_s_stream(struct v4l2_subdev *subdev, int on)
+{
+   struct sun6i_mipi_csi2_video *video =
+   sun6i_mipi_csi2_subdev_video(subdev);
+   struct sun6i_mipi_csi2_dev *cdev = sun6i_mipi_csi2_video_dev(video);
+   struct v4l2_subdev *remote_subdev = video->remote_subdev;
+   struct v4l2_fwnode_bus_mipi_csi2 *bus_mipi_csi2 =
+   >endpoint.bus.mipi_csi2;
+   union phy_configure_opts dphy_opts = { 0 };
+   struct phy_configure_opts_mipi_dphy *dphy_cfg = _opts.mipi_dphy;
+   struct regmap *regmap = cdev->regmap;
+

[PATCH v5 15/16] ARM: dts: sun8i: a83t: Add MIPI CSI-2 controller node

2021-01-15 Thread Paul Kocialkowski
MIPI CSI-2 is supported on the A83T with a dedicated controller that
covers both the protocol and D-PHY. It can be connected to the CSI
interface as a V4L2 subdev through the fwnode graph.

This is not done by default since connecting the bridge without a
subdev attached to it will cause a failure on the CSI driver.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index c010b27fdb6a..d6d55c12b995 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -1066,6 +1066,32 @@ csi_in: port {
};
};
 
+   mipi_csi2: csi@1cb1000 {
+   compatible = "allwinner,sun8i-a83t-mipi-csi2";
+   reg = <0x01cb1000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_CSI>,
+< CLK_CSI_SCLK>,
+< CLK_MIPI_CSI>,
+< CLK_CSI_MISC>;
+   clock-names = "bus", "mod", "mipi", "misc";
+   resets = < RST_BUS_CSI>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mipi_csi2_in: port@0 {
+   reg = <0>;
+   };
+
+   mipi_csi2_out: port@1 {
+   reg = <1>;
+   };
+   };
+   };
+
hdmi: hdmi@1ee {
compatible = "allwinner,sun8i-a83t-dw-hdmi";
reg = <0x01ee 0x1>;
-- 
2.30.0



[PATCH v5 16/16] MAINTAINERS: Add entry for the Allwinner A83T MIPI CSI-2 bridge

2021-01-15 Thread Paul Kocialkowski
Add myself as maintainer of the A83T MIPI CSI-2 bridge media driver.

Signed-off-by: Paul Kocialkowski 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index a41c41f6387c..af8095085f0f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -718,6 +718,14 @@ T: git git://linuxtv.org/media_tree.git
 F: 
Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
 F: drivers/media/platform/sunxi/sun6i-mipi-csi2/
 
+ALLWINNER A83T MIPI CSI-2 BRIDGE
+M: Paul Kocialkowski 
+L: linux-me...@vger.kernel.org
+S: Maintained
+T: git git://linuxtv.org/media_tree.git
+F: 
Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml
+F: drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/
+
 ALLWINNER CPUFREQ DRIVER
 M: Yangtao Li 
 L: linux...@vger.kernel.org
-- 
2.30.0



[PATCH v5 00/16] Allwinner MIPI CSI-2 support for A31/V3s/A83T

2021-01-15 Thread Paul Kocialkowski
ling: OK

Codec ioctls (Input 0):
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls (Input 0):
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
fail: v4l2-test-buffers.cpp(755): q.export_bufs(node, 
q.g_type())
test VIDIOC_EXPBUF: FAIL
test Requests: OK (Not Supported)

Total for sun6i-video device /dev/video0: 45, Succeeded: 44, Failed: 1, 
Warnings: 1

# sun6i-csi + sun8i-a83t-mipi-csi2 + ov8865

v4l2-compliance SHA: not available, 32 bits

Compliance test for sun6i-video device /dev/video0:

Driver Info:
Driver name  : sun6i-video
Card type: sun6i-csi
Bus info : platform:camera
Driver version   : 5.10.0
Capabilities : 0x8421
Video Capture
Streaming
Extended Pix Format
Device Capabilities
Device Caps  : 0x0421
Video Capture
Streaming
Extended Pix Format
Media Driver Info:
Driver name  : sun6i-csi
Model: Allwinner Video Capture Device
Serial   : 
Bus info : platform:1cb.camera
Media version: 5.10.0
Hardware revision: 0x (0)
Driver version   : 5.10.0
Interface Info:
ID   : 0x0304
Type : V4L Video
Entity Info:
ID   : 0x0001 (1)
Name : sun6i-csi
Function : V4L2 I/O
Pad 0x0102   : 0: Sink
Pad 0x0103   : 1: Sink
  Link 0x020d: from remote pad 0x108 of entity 
'sun8i-a83t-mipi-csi2': Data, Enabled

Required ioctls:
test MC information (see 'Media Driver Info' above): OK
warn: v4l2-compliance.cpp(633): media bus_info 
'platform:1cb.camera' differs from V4L2 bus_info 'platform:camera'
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second /dev/video0 open: OK
warn: v4l2-compliance.cpp(633): media bus_info 
'platform:1cb.camera' differs from V4L2 bus_info 'platform:camera'
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls (Input 0):
warn: v4l2-test-controls.cpp(92): Exposure: (max - min) % step 
!= 0
warn: v4l2-test-controls.cpp(92): Gain: (max - min) % step != 0
warn: v4l2-test-controls.cpp(92): Exposure: (max - min) % step 
!= 0
warn: v4l2-test-controls.cpp(92): Gain: (max - min) % step != 0
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 11 Private Controls: 0

Format ioctls (Input 0):
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK

Codec ioctls (Input 0):
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls (Input 0):
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK
test Requests: OK (Not Supported)

Total for sun6i-video device /dev/video0: 45, Succeeded: 45, Failed: 0, 
Warnings: 6


[PATCH v5 01/16] docs: phy: Add a part about PHY mode and submode

2021-01-15 Thread Paul Kocialkowski
Besides giving pointers to the relevant functions for PHY mode and
submode configuration, this clarifies the need to set them before
powering on the PHY.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Maxime Ripard 
---
 Documentation/driver-api/phy/phy.rst | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/driver-api/phy/phy.rst 
b/Documentation/driver-api/phy/phy.rst
index 8fc1ce0bb905..6cbc72707a49 100644
--- a/Documentation/driver-api/phy/phy.rst
+++ b/Documentation/driver-api/phy/phy.rst
@@ -195,3 +195,21 @@ DeviceTree Binding
 
 The documentation for PHY dt binding can be found @
 Documentation/devicetree/bindings/phy/phy-bindings.txt
+
+PHY Mode and Submode
+
+
+Once a reference to a PHY is obtained by a controller, the PHY can be 
configured
+to a PHY mode and submode. PHY modes are described in the `phy_mode` enum while
+submodes are specific to the selected PHY mode.
+
+Mode and submode configuration is done by calling::
+
+   int phy_set_mode_ext(struct phy *phy, enum phy_mode mode, int submode);
+
+If no submode is to be configured, users can call::
+
+   int phy_set_mode(struct phy *phy, enum phy_mode mode);
+
+The PHY mode and submode must not be configured after the PHY has already been
+powered on.
-- 
2.30.0



[PATCH v5 14/16] media: sunxi: Add support for the A83T MIPI CSI-2 controller

2021-01-15 Thread Paul Kocialkowski
The A83T supports MIPI CSI-2 with a composite controller, covering
both the protocol logic and the D-PHY implementation. This controller
seems to be found on the A83T only and probably was abandoned since.

This implementation splits the protocol and D-PHY registers and
uses the PHY framework internally. The D-PHY is not registered as a
standalone PHY driver since it cannot be used with any other
controller.

There are a few notable points about the controller:
- The initialisation sequence involes writing specific magic init
  values that do not seem to make any particular sense given the
  concerned register fields;
- Interrupts appear to be hitting regardless of the interrupt mask
  registers, which can cause a serious flood when transmission errors
  occur.

Only 8-bit and 10-bit Bayer formats are currently supported.
While up to 4 internal channels to the CSI controller exist, only one
is currently supported by this implementation.

This work is based on the first version of the driver submitted by
Kévin L'hôpital, which was adapted to mainline from the Allwinner BSP.
This version integrates MIPI CSI-2 support as a standalone V4L2 subdev
instead of merging it in the sun6i-csi driver.

It was tested on a Banana Pi M3 board with an OV8865 sensor in a 4-lane
configuration.

Signed-off-by: Paul Kocialkowski 
Acked-by: Maxime Ripard 
---
 drivers/media/platform/sunxi/Kconfig  |   1 +
 drivers/media/platform/sunxi/Makefile |   1 +
 .../sunxi/sun8i-a83t-mipi-csi2/Kconfig|  11 +
 .../sunxi/sun8i-a83t-mipi-csi2/Makefile   |   4 +
 .../sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.c|  92 +++
 .../sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.h|  39 +
 .../sun8i_a83t_mipi_csi2.c| 666 ++
 .../sun8i_a83t_mipi_csi2.h| 197 ++
 8 files changed, 1011 insertions(+)
 create mode 100644 drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Kconfig
 create mode 100644 drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Makefile
 create mode 100644 
drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.c
 create mode 100644 
drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.h
 create mode 100644 
drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_mipi_csi2.c
 create mode 100644 
drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_mipi_csi2.h

diff --git a/drivers/media/platform/sunxi/Kconfig 
b/drivers/media/platform/sunxi/Kconfig
index 9684e07454ad..db4c07be7e4c 100644
--- a/drivers/media/platform/sunxi/Kconfig
+++ b/drivers/media/platform/sunxi/Kconfig
@@ -3,3 +3,4 @@
 source "drivers/media/platform/sunxi/sun4i-csi/Kconfig"
 source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
 source "drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig"
+source "drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Kconfig"
diff --git a/drivers/media/platform/sunxi/Makefile 
b/drivers/media/platform/sunxi/Makefile
index 887a7cae8fca..9aa01cb01883 100644
--- a/drivers/media/platform/sunxi/Makefile
+++ b/drivers/media/platform/sunxi/Makefile
@@ -3,5 +3,6 @@
 obj-y  += sun4i-csi/
 obj-y  += sun6i-csi/
 obj-y  += sun6i-mipi-csi2/
+obj-y  += sun8i-a83t-mipi-csi2/
 obj-y  += sun8i-di/
 obj-y  += sun8i-rotate/
diff --git a/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Kconfig 
b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Kconfig
new file mode 100644
index ..60e7a9c41065
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Kconfig
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config VIDEO_SUN8I_A83T_MIPI_CSI2
+   tristate "Allwinner A83T MIPI CSI-2 Controller and D-PHY Driver"
+   depends on ARCH_SUNXI || COMPILE_TEST
+   depends on PM && COMMON_CLK && VIDEO_V4L2
+   select REGMAP_MMIO
+   select MEDIA_CONTROLLER
+   select VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+   help
+  Support for the Allwinner A83T MIPI CSI-2 Controller and D-PHY.
diff --git a/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Makefile 
b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Makefile
new file mode 100644
index ..1427d15a879a
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-only
+sun8i-a83t-mipi-csi2-y += sun8i_a83t_mipi_csi2.o sun8i_a83t_dphy.o
+
+obj-$(CONFIG_VIDEO_SUN8I_A83T_MIPI_CSI2) += sun8i-a83t-mipi-csi2.o
diff --git 
a/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.c 
b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.c
new file mode 100644
index ..c380065eb7c9
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.c
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 Bootlin
+ * Author: Paul Kocialkowski 
+ */

[PATCH v5 11/16] ARM: dts: sun8i: v3s: Add nodes for MIPI CSI-2 support

2021-01-15 Thread Paul Kocialkowski
MIPI CSI-2 is supported on the V3s with an A31-based MIPI CSI-2 bridge
controller. The controller uses a separate D-PHY, which is the same
that is otherwise used for MIPI DSI, but used in Rx mode.

On the V3s, the CSI0 controller is dedicated to MIPI CSI-2 as it does
not have access to any parallel interface pins.

Add all the necessary nodes (CSI0, MIPI CSI-2 bridge and D-PHY) to
support the MIPI CSI-2 interface.

Note that a fwnode graph link is created between CSI0 and MIPI CSI-2
even when no sensor is connected. This will result in a probe failure
for the controller as long as no sensor is connected but this is fine
since no other interface is available.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun8i-v3s.dtsi | 68 
 1 file changed, 68 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index f8f19d8fa795..7eae0295ba73 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -530,6 +530,31 @@ spi0: spi@1c68000 {
#size-cells = <0>;
};
 
+   csi0: camera@1cb {
+   compatible = "allwinner,sun8i-v3s-csi";
+   reg = <0x01cb 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_CSI>,
+< CLK_CSI1_SCLK>,
+< CLK_DRAM_CSI>;
+   clock-names = "bus", "mod", "ram";
+   resets = < RST_BUS_CSI>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+
+   csi0_in_mipi_csi2: endpoint {
+   remote-endpoint = 
<_csi2_out_csi0>;
+   };
+   };
+   };
+   };
+
csi1: camera@1cb4000 {
compatible = "allwinner,sun8i-v3s-csi";
reg = <0x01cb4000 0x3000>;
@@ -552,5 +577,48 @@ gic: interrupt-controller@1c81000 {
#interrupt-cells = <3>;
interrupts = ;
};
+
+   mipi_csi2: csi@1cb1000 {
+   compatible = "allwinner,sun8i-v3s-mipi-csi2",
+"allwinner,sun6i-a31-mipi-csi2";
+   reg = <0x01cb1000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_CSI>,
+< CLK_CSI1_SCLK>;
+   clock-names = "bus", "mod";
+   resets = < RST_BUS_CSI>;
+   status = "disabled";
+
+   phys = <>;
+   phy-names = "dphy";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mipi_csi2_in: port@0 {
+   reg = <0>;
+   };
+
+   mipi_csi2_out: port@1 {
+   reg = <1>;
+
+   mipi_csi2_out_csi0: endpoint {
+   remote-endpoint = 
<_in_mipi_csi2>;
+   };
+   };
+   };
+   };
+
+   dphy: d-phy@1cb2000 {
+   compatible = "allwinner,sun6i-a31-mipi-dphy";
+   reg = <0x01cb2000 0x1000>;
+   clocks = < CLK_BUS_CSI>,
+< CLK_MIPI_CSI>;
+   clock-names = "bus", "mod";
+   resets = < RST_BUS_CSI>;
+   status = "disabled";
+   #phy-cells = <0>;
+   };
};
 };
-- 
2.30.0



[PATCH v5 12/16] MAINTAINERS: Add entry for the Allwinner A31 MIPI CSI-2 bridge

2021-01-15 Thread Paul Kocialkowski
Add myself as maintainer of the A31 MIPI CSI-2 bridge media driver.

Signed-off-by: Paul Kocialkowski 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 57f9e3047227..a41c41f6387c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -710,6 +710,14 @@ T: git git://linuxtv.org/media_tree.git
 F: Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml
 F: drivers/media/platform/sunxi/sun4i-csi/
 
+ALLWINNER A31 MIPI CSI-2 BRIDGE
+M: Paul Kocialkowski 
+L: linux-me...@vger.kernel.org
+S: Maintained
+T: git git://linuxtv.org/media_tree.git
+F: 
Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
+F: drivers/media/platform/sunxi/sun6i-mipi-csi2/
+
 ALLWINNER CPUFREQ DRIVER
 M: Yangtao Li 
 L: linux...@vger.kernel.org
-- 
2.30.0



[PATCH v5 08/16] media: sun6i-csi: Add support for MIPI CSI-2 bridge input

2021-01-15 Thread Paul Kocialkowski
The A31 CSI controller supports a MIPI CSI-2 bridge input, which has
its own dedicated port in the fwnode graph.

Support for this input is added with this change:
- two pads are defined for the media entity instead of one
  and only one needs to be connected at a time;
- the pads currently match the fwnode graph representation;
- links are created between our pads and the subdevs for each
  interface and are no longer immutable so that userspace can select
  which interface to use in case both are bound to a subdev;
- fwnode endpoints are parsed and stored for each interface;
- the active subdev (and fwnode endpoint) is retrieved when validating
  the media link at stream on time and cleared at stream off;
- an error is raised if both links are active at the same time;
- the MIPI interface bit is set if the MIPI CSI-2 bridge endpoint is
  active.

In the future, the media entity representation might evolve to:
- distinguish the internal parallel bridge and data formatter;
- represent each of the 4 internal channels that can exist between
  the parallel bridge (for BT656 time-multiplex) and MIPI CSI-2
  (internal channels can be mapped to virtual channels);
- connect the controller's output to the ISP instead of its
  DMA engine.

Finally note that the MIPI CSI-2 bridges should not be linked in
the fwnode graph unless they have a sensor subdev attached.

Signed-off-by: Paul Kocialkowski 
Acked-by: Maxime Ripard 
---
 .../platform/sunxi/sun6i-csi/sun6i_csi.c  | 111 +++---
 .../platform/sunxi/sun6i-csi/sun6i_csi.h  |   9 +-
 .../platform/sunxi/sun6i-csi/sun6i_video.c|  57 +
 .../platform/sunxi/sun6i-csi/sun6i_video.h|   7 +-
 4 files changed, 137 insertions(+), 47 deletions(-)

diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
index d06028f42534..55cac91f8282 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -49,6 +49,7 @@ static inline struct sun6i_csi_dev *sun6i_csi_to_dev(struct 
sun6i_csi *csi)
 
 /* TODO add 10&12 bit YUV, RGB support */
 bool sun6i_csi_is_format_supported(struct sun6i_csi *csi,
+  struct v4l2_fwnode_endpoint *endpoint,
   u32 pixformat, u32 mbus_code)
 {
struct sun6i_csi_dev *sdev = sun6i_csi_to_dev(csi);
@@ -58,9 +59,9 @@ bool sun6i_csi_is_format_supported(struct sun6i_csi *csi,
 * 8bit and 16bit bus width.
 * Identify the media bus format from device tree.
 */
-   if ((sdev->csi.v4l2_ep.bus_type == V4L2_MBUS_PARALLEL
-|| sdev->csi.v4l2_ep.bus_type == V4L2_MBUS_BT656)
-&& sdev->csi.v4l2_ep.bus.parallel.bus_width == 16) {
+   if ((endpoint->bus_type == V4L2_MBUS_PARALLEL ||
+endpoint->bus_type == V4L2_MBUS_BT656) &&
+   endpoint->bus.parallel.bus_width == 16) {
switch (pixformat) {
case V4L2_PIX_FMT_HM12:
case V4L2_PIX_FMT_NV12:
@@ -373,7 +374,7 @@ static enum csi_input_seq get_csi_input_seq(struct 
sun6i_csi_dev *sdev,
 
 static void sun6i_csi_setup_bus(struct sun6i_csi_dev *sdev)
 {
-   struct v4l2_fwnode_endpoint *endpoint = >csi.v4l2_ep;
+   struct v4l2_fwnode_endpoint *endpoint = sdev->csi.video.source_endpoint;
struct sun6i_csi *csi = >csi;
unsigned char bus_width;
u32 flags;
@@ -459,6 +460,9 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev *sdev)
if (flags & V4L2_MBUS_PCLK_SAMPLE_FALLING)
cfg |= CSI_IF_CFG_CLK_POL_FALLING_EDGE;
break;
+   case V4L2_MBUS_CSI2_DPHY:
+   cfg |= CSI_IF_CFG_MIPI_IF_MIPI;
+   break;
default:
dev_warn(sdev->dev, "Unsupported bus type: %d\n",
 endpoint->bus_type);
@@ -636,11 +640,11 @@ void sun6i_csi_set_stream(struct sun6i_csi *csi, bool 
enable)
  * Media Controller and V4L2
  */
 static int sun6i_csi_link_entity(struct sun6i_csi *csi,
+struct media_pad *sink_pad,
 struct media_entity *entity,
-struct fwnode_handle *fwnode)
+struct fwnode_handle *fwnode, bool enabled)
 {
struct media_entity *sink;
-   struct media_pad *sink_pad;
int src_pad_index;
int ret;
 
@@ -654,14 +658,12 @@ static int sun6i_csi_link_entity(struct sun6i_csi *csi,
src_pad_index = ret;
 
sink = >video.vdev.entity;
-   sink_pad = >video.pad;
 
dev_dbg(csi->dev, "creating %s:%u -> %s:%u link\n",
entity->name, src_pad_index, sink->name, sink_pad->index);
ret = media_create_pad_link(entity, src_pad_index, sink,
   

[PATCH v5 07/16] dt-bindings: media: sun6i-a31-csi: Add MIPI CSI-2 input port

2021-01-15 Thread Paul Kocialkowski
The A31 CSI controller supports two distinct input interfaces:
parallel and an external MIPI CSI-2 bridge. The parallel interface
is often connected to a set of hardware pins while the MIPI CSI-2
bridge is an internal FIFO-ish link. As a result, these two inputs
are distinguished as two different ports.

Note that only one of the two may be present on a controller instance.
For example, the V3s has one controller dedicated to MIPI-CSI2 and one
dedicated to parallel.

Update the binding with an explicit ports node that holds two distinct
port nodes: one for parallel input and one for MIPI CSI-2.

This is backward-compatible with the single-port approach that was
previously taken for representing the parallel interface port, which
stays enumerated as fwnode port 0.

Note that additional ports may be added in the future, especially to
support feeding the CSI controller's output to the ISP.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Rob Herring 
Acked-by: Maxime Ripard 
---
 .../media/allwinner,sun6i-a31-csi.yaml| 88 ---
 1 file changed, 75 insertions(+), 13 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml 
b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
index 1fd9b5532a21..77ded77505e9 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
@@ -67,6 +67,62 @@ properties:
 
 additionalProperties: false
 
+  ports:
+type: object
+
+properties:
+  port@0:
+type: object
+description: Parallel input port, connect to a parallel sensor
+
+properties:
+  reg:
+const: 0
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+  bus-width:
+enum: [ 8, 10, 12, 16 ]
+
+  pclk-sample: true
+  hsync-active: true
+  vsync-active: true
+
+required:
+  - bus-width
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
+  port@1:
+type: object
+description: MIPI CSI-2 bridge input port
+
+properties:
+  reg:
+const: 1
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+required:
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
 required:
   - compatible
   - reg
@@ -95,19 +151,25 @@ examples:
   "ram";
 resets = < RST_BUS_CSI>;
 
-port {
-/* Parallel bus endpoint */
-csi1_ep: endpoint {
-remote-endpoint = <_ep>;
-bus-width = <16>;
-
-/*
- * If hsync-active/vsync-active are missing,
- * embedded BT.656 sync is used.
- */
- hsync-active = <0>; /* Active low */
- vsync-active = <0>; /* Active low */
- pclk-sample = <1>;  /* Rising */
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+/* Parallel bus endpoint */
+csi1_ep: endpoint {
+remote-endpoint = <_ep>;
+bus-width = <16>;
+
+/*
+ * If hsync-active/vsync-active are missing,
+ * embedded BT.656 sync is used.
+ */
+ hsync-active = <0>; /* Active low */
+ vsync-active = <0>; /* Active low */
+ pclk-sample = <1>;  /* Rising */
+};
 };
 };
 };
-- 
2.30.0



[PATCH v5 09/16] dt-bindings: media: Add A31 MIPI CSI-2 bindings documentation

2021-01-15 Thread Paul Kocialkowski
This introduces YAML bindings documentation for the A31 MIPI CSI-2
controller.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Maxime Ripard 
Reviewed-by: Rob Herring 
---
 .../media/allwinner,sun6i-a31-mipi-csi2.yaml  | 156 ++
 1 file changed, 156 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml

diff --git 
a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml 
b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
new file mode 100644
index ..309336b93a87
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
@@ -0,0 +1,156 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/allwinner,sun6i-a31-mipi-csi2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A31 MIPI CSI-2 Device Tree Bindings
+
+maintainers:
+  - Paul Kocialkowski 
+
+properties:
+  compatible:
+oneOf:
+  - const: allwinner,sun6i-a31-mipi-csi2
+  - items:
+  - const: allwinner,sun8i-v3s-mipi-csi2
+  - const: allwinner,sun6i-a31-mipi-csi2
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+items:
+  - description: Bus Clock
+  - description: Module Clock
+
+  clock-names:
+items:
+  - const: bus
+  - const: mod
+
+  phys:
+maxItems: 1
+description: MIPI D-PHY
+
+  phy-names:
+items:
+  - const: dphy
+
+  resets:
+maxItems: 1
+
+  # See ./video-interfaces.txt for details
+  ports:
+type: object
+
+properties:
+  port@0:
+type: object
+description: Input port, connect to a MIPI CSI-2 sensor
+
+properties:
+  reg:
+const: 0
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+  data-lanes:
+minItems: 1
+maxItems: 4
+
+required:
+  - data-lanes
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
+  port@1:
+type: object
+description: Output port, connect to a CSI controller
+
+properties:
+  reg:
+const: 1
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+required:
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - phys
+  - phy-names
+  - resets
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+
+mipi_csi2: csi@1cb1000 {
+compatible = "allwinner,sun8i-v3s-mipi-csi2",
+ "allwinner,sun6i-a31-mipi-csi2";
+reg = <0x01cb1000 0x1000>;
+interrupts = ;
+clocks = < CLK_BUS_CSI>,
+ < CLK_CSI1_SCLK>;
+clock-names = "bus", "mod";
+resets = < RST_BUS_CSI>;
+
+phys = <>;
+phy-names = "dphy";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+mipi_csi2_in: port@0 {
+reg = <0>;
+
+mipi_csi2_in_ov5648: endpoint {
+data-lanes = <1 2 3 4>;
+
+remote-endpoint = <_out_mipi_csi2>;
+};
+};
+
+mipi_csi2_out: port@1 {
+reg = <1>;
+
+mipi_csi2_out_csi0: endpoint {
+remote-endpoint = <_in_mipi_csi2>;
+};
+};
+};
+};
+
+...
-- 
2.30.0



[PATCH v5 05/16] media: sun6i-csi: Use common V4L2 format info for storage bpp

2021-01-15 Thread Paul Kocialkowski
V4L2 has a common helper which can be used for calculating the number
of stored bits per pixels of a given (stored) image format.

Use the helper-returned structure instead of our own switch/case list.
Note that a few formats are not in that list so we keep them as
special cases.

The custom switch/case was also wrong concerning 10/12-bit Bayer
formats, which are aligned to 16 bits in memory. Using the common
helper fixes it.

Fixes: 5cc7522d8965 ("media: sun6i: Add support for Allwinner CSI V3s")
Signed-off-by: Paul Kocialkowski 
Acked-by: Maxime Ripard 
---
 .../platform/sunxi/sun6i-csi/sun6i_csi.h  | 55 +++
 1 file changed, 20 insertions(+), 35 deletions(-)

diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
index 7f3389c70794..7cd23cd74685 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
@@ -87,53 +87,38 @@ void sun6i_csi_update_buf_addr(struct sun6i_csi *csi, 
dma_addr_t addr);
  */
 void sun6i_csi_set_stream(struct sun6i_csi *csi, bool enable);
 
-/* get bpp form v4l2 pixformat */
+/* get memory storage bpp from v4l2 pixformat */
 static inline int sun6i_csi_get_bpp(unsigned int pixformat)
 {
+   const struct v4l2_format_info *info;
+   unsigned int i;
+   int bpp = 0;
+
+   /* Handle special cases unknown to V4L2 format info first. */
switch (pixformat) {
-   case V4L2_PIX_FMT_SBGGR8:
-   case V4L2_PIX_FMT_SGBRG8:
-   case V4L2_PIX_FMT_SGRBG8:
-   case V4L2_PIX_FMT_SRGGB8:
case V4L2_PIX_FMT_JPEG:
return 8;
-   case V4L2_PIX_FMT_SBGGR10:
-   case V4L2_PIX_FMT_SGBRG10:
-   case V4L2_PIX_FMT_SGRBG10:
-   case V4L2_PIX_FMT_SRGGB10:
-   return 10;
-   case V4L2_PIX_FMT_SBGGR12:
-   case V4L2_PIX_FMT_SGBRG12:
-   case V4L2_PIX_FMT_SGRBG12:
-   case V4L2_PIX_FMT_SRGGB12:
case V4L2_PIX_FMT_HM12:
-   case V4L2_PIX_FMT_NV12:
-   case V4L2_PIX_FMT_NV21:
-   case V4L2_PIX_FMT_YUV420:
-   case V4L2_PIX_FMT_YVU420:
return 12;
-   case V4L2_PIX_FMT_YUYV:
-   case V4L2_PIX_FMT_YVYU:
-   case V4L2_PIX_FMT_UYVY:
-   case V4L2_PIX_FMT_VYUY:
-   case V4L2_PIX_FMT_NV16:
-   case V4L2_PIX_FMT_NV61:
-   case V4L2_PIX_FMT_YUV422P:
-   case V4L2_PIX_FMT_RGB565:
case V4L2_PIX_FMT_RGB565X:
return 16;
-   case V4L2_PIX_FMT_RGB24:
-   case V4L2_PIX_FMT_BGR24:
-   return 24;
-   case V4L2_PIX_FMT_RGB32:
-   case V4L2_PIX_FMT_BGR32:
-   return 32;
-   default:
+   }
+
+   info = v4l2_format_info(pixformat);
+   if (!info) {
WARN(1, "Unsupported pixformat: 0x%x\n", pixformat);
-   break;
+   return 0;
+   }
+
+   for (i = 0; i < info->comp_planes; i++) {
+   unsigned int hdiv = (i == 0) ? 1 : info->hdiv;
+   unsigned int vdiv = (i == 0) ? 1 : info->vdiv;
+
+   /* We return bits per pixel while V4L2 format info is bytes. */
+   bpp += 8 * info->bpp[i] / hdiv / vdiv;
}
 
-   return 0;
+   return bpp;
 }
 
 #endif /* __SUN6I_CSI_H__ */
-- 
2.30.0



[PATCH v5 06/16] media: sun6i-csi: Only configure the interface data width for parallel

2021-01-15 Thread Paul Kocialkowski
Bits related to the interface data width are only applicable to the
parallel interface and are irrelevant when the CSI controller is taking
input from the MIPI CSI-2 controller.

In prevision of adding support for this case, set these bits
conditionally so there is no ambiguity. The conditional block is
moved around before the interlaced conditional block for nicer code
symmetry (conditional blocks first) while at it.

Co-developed-by: Kévin L'hôpital 
Signed-off-by: Kévin L'hôpital 
Signed-off-by: Paul Kocialkowski 
Acked-by: Maxime Ripard 
---
 .../platform/sunxi/sun6i-csi/sun6i_csi.c  | 42 +++
 1 file changed, 25 insertions(+), 17 deletions(-)

diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
index 1a11a6174a17..d06028f42534 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -378,8 +378,13 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev *sdev)
unsigned char bus_width;
u32 flags;
u32 cfg;
+   bool input_parallel = false;
bool input_interlaced = false;
 
+   if (endpoint->bus_type == V4L2_MBUS_PARALLEL ||
+   endpoint->bus_type == V4L2_MBUS_BT656)
+   input_parallel = true;
+
if (csi->config.field == V4L2_FIELD_INTERLACED
|| csi->config.field == V4L2_FIELD_INTERLACED_TB
|| csi->config.field == V4L2_FIELD_INTERLACED_BT)
@@ -395,6 +400,26 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev *sdev)
 CSI_IF_CFG_HREF_POL_MASK | CSI_IF_CFG_FIELD_MASK |
 CSI_IF_CFG_SRC_TYPE_MASK);
 
+   if (input_parallel) {
+   switch (bus_width) {
+   case 8:
+   cfg |= CSI_IF_CFG_IF_DATA_WIDTH_8BIT;
+   break;
+   case 10:
+   cfg |= CSI_IF_CFG_IF_DATA_WIDTH_10BIT;
+   break;
+   case 12:
+   cfg |= CSI_IF_CFG_IF_DATA_WIDTH_12BIT;
+   break;
+   case 16: /* No need to configure DATA_WIDTH for 16bit */
+   break;
+   default:
+   dev_warn(sdev->dev, "Unsupported bus width: %u\n",
+bus_width);
+   break;
+   }
+   }
+
if (input_interlaced)
cfg |= CSI_IF_CFG_SRC_TYPE_INTERLACED;
else
@@ -440,23 +465,6 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev *sdev)
break;
}
 
-   switch (bus_width) {
-   case 8:
-   cfg |= CSI_IF_CFG_IF_DATA_WIDTH_8BIT;
-   break;
-   case 10:
-   cfg |= CSI_IF_CFG_IF_DATA_WIDTH_10BIT;
-   break;
-   case 12:
-   cfg |= CSI_IF_CFG_IF_DATA_WIDTH_12BIT;
-   break;
-   case 16: /* No need to configure DATA_WIDTH for 16bit */
-   break;
-   default:
-   dev_warn(sdev->dev, "Unsupported bus width: %u\n", bus_width);
-   break;
-   }
-
regmap_write(sdev->regmap, CSI_IF_CFG_REG, cfg);
 }
 
-- 
2.30.0



[PATCH v5 04/16] media: sun6i-csi: Stop using the deprecated fwnode endpoint parser

2021-01-15 Thread Paul Kocialkowski
The v4l2_async_notifier_parse_fwnode_endpoints helper is getting
deprecated in favor of explicit parsing of the endpoints.

Implement it instead of using this deprecated function.

Since this was the last user of the helper, it should now be safe to
remove.

Signed-off-by: Paul Kocialkowski 
---
 .../platform/sunxi/sun6i-csi/sun6i_csi.c  | 69 ---
 .../platform/sunxi/sun6i-csi/sun6i_csi.h  |  1 +
 2 files changed, 44 insertions(+), 26 deletions(-)

diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
index c3b2f27b99d2..1a11a6174a17 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -693,28 +693,6 @@ static const struct v4l2_async_notifier_operations 
sun6i_csi_async_ops = {
.complete = sun6i_subdev_notify_complete,
 };
 
-static int sun6i_csi_fwnode_parse(struct device *dev,
- struct v4l2_fwnode_endpoint *vep,
- struct v4l2_async_subdev *asd)
-{
-   struct sun6i_csi *csi = dev_get_drvdata(dev);
-
-   if (vep->base.port || vep->base.id) {
-   dev_warn(dev, "Only support a single port with one endpoint\n");
-   return -ENOTCONN;
-   }
-
-   switch (vep->bus_type) {
-   case V4L2_MBUS_PARALLEL:
-   case V4L2_MBUS_BT656:
-   csi->v4l2_ep = *vep;
-   return 0;
-   default:
-   dev_err(dev, "Unsupported media bus type\n");
-   return -ENOTCONN;
-   }
-}
-
 static void sun6i_csi_v4l2_cleanup(struct sun6i_csi *csi)
 {
media_device_unregister(>media_dev);
@@ -726,6 +704,48 @@ static void sun6i_csi_v4l2_cleanup(struct sun6i_csi *csi)
media_device_cleanup(>media_dev);
 }
 
+static int sun6i_csi_v4l2_fwnode_init(struct sun6i_csi *csi)
+{
+   struct v4l2_fwnode_endpoint *endpoint = NULL;
+   struct fwnode_handle *handle = NULL;
+   int ret;
+
+   /* Parallel */
+
+   endpoint = >v4l2_ep;
+   handle = fwnode_graph_get_endpoint_by_id(dev_fwnode(csi->dev), 0, 0,
+FWNODE_GRAPH_ENDPOINT_NEXT);
+   if (!handle)
+   return 0;
+
+   ret = v4l2_fwnode_endpoint_parse(handle, endpoint);
+   if (ret)
+   goto error;
+
+   if (endpoint->bus_type != V4L2_MBUS_PARALLEL &&
+   endpoint->bus_type != V4L2_MBUS_BT656) {
+   dev_err(csi->dev, "Unsupported parallel media bus type\n");
+   ret = -ENOTCONN;
+   goto error;
+   }
+
+   ret = v4l2_async_notifier_add_fwnode_remote_subdev(>notifier,
+  handle,
+  >subdev);
+   if (ret)
+   goto error;
+
+   fwnode_handle_put(handle);
+
+   return 0;
+
+error:
+   if (handle)
+   fwnode_handle_put(handle);
+
+   return ret;
+}
+
 static int sun6i_csi_v4l2_init(struct sun6i_csi *csi)
 {
int ret;
@@ -760,10 +780,7 @@ static int sun6i_csi_v4l2_init(struct sun6i_csi *csi)
if (ret)
goto unreg_v4l2;
 
-   ret = v4l2_async_notifier_parse_fwnode_endpoints(csi->dev,
->notifier,
-sizeof(struct 
v4l2_async_subdev),
-
sun6i_csi_fwnode_parse);
+   ret = sun6i_csi_v4l2_fwnode_init(csi);
if (ret)
goto clean_video;
 
diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
index c626821aaedb..7f3389c70794 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
@@ -38,6 +38,7 @@ struct sun6i_csi {
struct v4l2_device  v4l2_dev;
struct media_device media_dev;
 
+   struct v4l2_async_subdevsubdev;
struct v4l2_async_notifier  notifier;
 
/* video port settings */
-- 
2.30.0



[PATCH v5 03/16] phy: allwinner: phy-sun6i-mipi-dphy: Support D-PHY Rx mode for MIPI CSI-2

2021-01-15 Thread Paul Kocialkowski
The Allwinner A31 D-PHY supports both Rx and Tx modes. While the latter
is already supported and used for MIPI DSI this adds support for the
former, to be used with MIPI CSI-2.

This implementation is inspired by Allwinner's V3s Linux SDK
implementation, which was used as a documentation base.

Signed-off-by: Paul Kocialkowski 
Acked-by: Maxime Ripard 
---
 drivers/phy/allwinner/phy-sun6i-mipi-dphy.c | 164 +++-
 1 file changed, 160 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c 
b/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
index f0bc87d654d4..326383e72528 100644
--- a/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
+++ b/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
@@ -24,6 +24,14 @@
 #define SUN6I_DPHY_TX_CTL_REG  0x04
 #define SUN6I_DPHY_TX_CTL_HS_TX_CLK_CONT   BIT(28)
 
+#define SUN6I_DPHY_RX_CTL_REG  0x08
+#define SUN6I_DPHY_RX_CTL_EN_DBC   BIT(31)
+#define SUN6I_DPHY_RX_CTL_RX_CLK_FORCE BIT(24)
+#define SUN6I_DPHY_RX_CTL_RX_D3_FORCE  BIT(23)
+#define SUN6I_DPHY_RX_CTL_RX_D2_FORCE  BIT(22)
+#define SUN6I_DPHY_RX_CTL_RX_D1_FORCE  BIT(21)
+#define SUN6I_DPHY_RX_CTL_RX_D0_FORCE  BIT(20)
+
 #define SUN6I_DPHY_TX_TIME0_REG0x10
 #define SUN6I_DPHY_TX_TIME0_HS_TRAIL(n)(((n) & 0xff) << 24)
 #define SUN6I_DPHY_TX_TIME0_HS_PREPARE(n)  (((n) & 0xff) << 16)
@@ -44,12 +52,29 @@
 #define SUN6I_DPHY_TX_TIME4_HS_TX_ANA1(n)  (((n) & 0xff) << 8)
 #define SUN6I_DPHY_TX_TIME4_HS_TX_ANA0(n)  ((n) & 0xff)
 
+#define SUN6I_DPHY_RX_TIME0_REG0x30
+#define SUN6I_DPHY_RX_TIME0_HS_RX_SYNC(n)  (((n) & 0xff) << 24)
+#define SUN6I_DPHY_RX_TIME0_HS_RX_CLK_MISS(n)  (((n) & 0xff) << 16)
+#define SUN6I_DPHY_RX_TIME0_LP_RX(n)   (((n) & 0xff) << 8)
+
+#define SUN6I_DPHY_RX_TIME1_REG0x34
+#define SUN6I_DPHY_RX_TIME1_RX_DLY(n)  (((n) & 0xfff) << 20)
+#define SUN6I_DPHY_RX_TIME1_LP_RX_ULPS_WP(n)   ((n) & 0xf)
+
+#define SUN6I_DPHY_RX_TIME2_REG0x38
+#define SUN6I_DPHY_RX_TIME2_HS_RX_ANA1(n)  (((n) & 0xff) << 8)
+#define SUN6I_DPHY_RX_TIME2_HS_RX_ANA0(n)  ((n) & 0xff)
+
+#define SUN6I_DPHY_RX_TIME3_REG0x40
+#define SUN6I_DPHY_RX_TIME3_LPRST_DLY(n)   (((n) & 0x) << 16)
+
 #define SUN6I_DPHY_ANA0_REG0x4c
 #define SUN6I_DPHY_ANA0_REG_PWSBIT(31)
 #define SUN6I_DPHY_ANA0_REG_DMPC   BIT(28)
 #define SUN6I_DPHY_ANA0_REG_DMPD(n)(((n) & 0xf) << 24)
 #define SUN6I_DPHY_ANA0_REG_SLV(n) (((n) & 7) << 12)
 #define SUN6I_DPHY_ANA0_REG_DEN(n) (((n) & 0xf) << 8)
+#define SUN6I_DPHY_ANA0_REG_SFB(n) (((n) & 3) << 2)
 
 #define SUN6I_DPHY_ANA1_REG0x50
 #define SUN6I_DPHY_ANA1_REG_VTTMODEBIT(31)
@@ -92,6 +117,8 @@ struct sun6i_dphy {
 
struct phy  *phy;
struct phy_configure_opts_mipi_dphy config;
+
+   int submode;
 };
 
 static int sun6i_dphy_init(struct phy *phy)
@@ -105,6 +132,18 @@ static int sun6i_dphy_init(struct phy *phy)
return 0;
 }
 
+static int sun6i_dphy_set_mode(struct phy *phy, enum phy_mode mode, int 
submode)
+{
+   struct sun6i_dphy *dphy = phy_get_drvdata(phy);
+
+   if (mode != PHY_MODE_MIPI_DPHY)
+   return -EINVAL;
+
+   dphy->submode = submode;
+
+   return 0;
+}
+
 static int sun6i_dphy_configure(struct phy *phy, union phy_configure_opts 
*opts)
 {
struct sun6i_dphy *dphy = phy_get_drvdata(phy);
@@ -119,9 +158,8 @@ static int sun6i_dphy_configure(struct phy *phy, union 
phy_configure_opts *opts)
return 0;
 }
 
-static int sun6i_dphy_power_on(struct phy *phy)
+static int sun6i_dphy_tx_power_on(struct sun6i_dphy *dphy)
 {
-   struct sun6i_dphy *dphy = phy_get_drvdata(phy);
u8 lanes_mask = GENMASK(dphy->config.lanes - 1, 0);
 
regmap_write(dphy->regs, SUN6I_DPHY_TX_CTL_REG,
@@ -211,12 +249,129 @@ static int sun6i_dphy_power_on(struct phy *phy)
return 0;
 }
 
+static int sun6i_dphy_rx_power_on(struct sun6i_dphy *dphy)
+{
+   /* Physical clock rate is actually half of symbol rate with DDR. */
+   unsigned long mipi_symbol_rate = dphy->config.hs_clk_rate;
+   unsigned long dphy_clk_rate;
+   unsigned int rx_dly;
+   unsigned int lprst_dly;
+   u32 value;
+
+   dphy_clk_rate = clk_get_rate(dphy->mod_clk);
+   if (!dphy_clk_rate)
+   return -EINVAL;
+
+   /* Hardcoded timing parameters from the Allwinner BSP. */
+   regmap_write(dphy->regs, SUN6I_DPHY_RX_TIME0_REG,
+SUN6I_DPHY_RX_TIME0_HS_RX_SYNC(255) |
+SUN6I_DPHY_RX_TIME0_HS_RX_CLK_MISS(255) |
+SUN6I

[PATCH 2/2] soc: sunxi: mbus: Remove DE2 display engine compatibles

2021-01-15 Thread Paul Kocialkowski
The DE2 display engine hardware takes physical addresses that do not
need PHYS_BASE subtracted. As a result, they should not be present
on the mbus driver match list. Remove them.

This was tested on the A83T, along with the patch allowing the DMA
range map to be non-NULL and restores a working display.

Fixes: b4bdc4fbf8d0 ("soc: sunxi: Deal with the MBUS DMA offsets in a central 
place")
Signed-off-by: Paul Kocialkowski 
---
 drivers/soc/sunxi/sunxi_mbus.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/soc/sunxi/sunxi_mbus.c b/drivers/soc/sunxi/sunxi_mbus.c
index e9925c8487d7..d90e4a264b6f 100644
--- a/drivers/soc/sunxi/sunxi_mbus.c
+++ b/drivers/soc/sunxi/sunxi_mbus.c
@@ -23,12 +23,7 @@ static const char * const sunxi_mbus_devices[] = {
"allwinner,sun7i-a20-display-engine",
"allwinner,sun8i-a23-display-engine",
"allwinner,sun8i-a33-display-engine",
-   "allwinner,sun8i-a83t-display-engine",
-   "allwinner,sun8i-h3-display-engine",
-   "allwinner,sun8i-r40-display-engine",
-   "allwinner,sun8i-v3s-display-engine",
"allwinner,sun9i-a80-display-engine",
-   "allwinner,sun50i-a64-display-engine",
 
/*
 * And now we have the regular devices connected to the MBUS
-- 
2.30.0



[PATCH 1/2] of: device: Allow DMA range map to be set before of_dma_configure_id

2021-01-15 Thread Paul Kocialkowski
A mechanism was recently introduced for the sunxi architecture where
the DMA offset for specific devices (under the MBUS) is set by a common
driver (sunxi_mbus). This driver calls dma_direct_set_offset to set
the device's dma_range_map manually.

However this information was overwritten by of_dma_configure_id, which
obtains the map from of_dma_get_range (or keeps it NULL when it fails
and the force_dma argument is true, which is the case for platform
devices).

As a result, the dma_range_map was always overwritten and the mechanism
could not correctly take effect.

This adds a check to ensure that no previous DMA range map is
overwritten and prints a warning when the map was already set while
also being available from dt. In this case, the map that was already
set is kept.

Fixes: b4bdc4fbf8d0 ("soc: sunxi: Deal with the MBUS DMA offsets in a central 
place")
Signed-off-by: Paul Kocialkowski 
---
 drivers/of/device.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index aedfaaafd3e7..db1b8634c2c7 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -181,7 +181,14 @@ int of_dma_configure_id(struct device *dev, struct 
device_node *np,
 
arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
 
-   dev->dma_range_map = map;
+   if (!dev->dma_range_map) {
+   dev->dma_range_map = map;
+   } else if (map) {
+   dev_warn(dev,
+"DMA range map was already set, ignoring range map 
from dt\n");
+   kfree(map);
+   }
+
return 0;
 }
 EXPORT_SYMBOL_GPL(of_dma_configure_id);
-- 
2.30.0



Re: [linux-sunxi] [PATCH v4 09/15] media: sunxi: Add support for the A31 MIPI CSI-2 controller

2021-01-14 Thread Paul Kocialkowski
Hey Ezequiel,

On Mon 11 Jan 21, 15:21, Ezequiel Garcia wrote:
> Salut Paul,
> 
> Just a minor comment about the v4l2 async API.
>
> On Thu, 31 Dec 2020 at 11:30, Paul Kocialkowski
>  wrote:
> >
> > The A31 MIPI CSI-2 controller is a dedicated MIPI CSI-2 bridge
> > found on Allwinner SoCs such as the A31 and V3/V3s.
> >
> > It is a standalone block, connected to the CSI controller on one side
> > and to the MIPI D-PHY block on the other. It has a dedicated address
> > space, interrupt line and clock.
> >
> > It is represented as a V4L2 subdev to the CSI controller and takes a
> > MIPI CSI-2 sensor as its own subdev, all using the fwnode graph and
> > media controller API.
> >
> > Only 8-bit and 10-bit Bayer formats are currently supported.
> > While up to 4 internal channels to the CSI controller exist, only one
> > is currently supported by this implementation.
> >
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  drivers/media/platform/sunxi/Kconfig  |   1 +
> >  drivers/media/platform/sunxi/Makefile |   1 +
> >  .../platform/sunxi/sun6i-mipi-csi2/Kconfig|  12 +
> >  .../platform/sunxi/sun6i-mipi-csi2/Makefile   |   4 +
> >  .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c   | 590 ++
> >  .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h   | 117 
> >  6 files changed, 725 insertions(+)
> >  create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
> >  create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
> >  create mode 100644 
> > drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
> >  create mode 100644 
> > drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h
> >
> [..]
> > +static int sun6i_mipi_csi2_v4l2_setup(struct sun6i_mipi_csi2_dev *cdev)
> > +{
> > +   struct sun6i_mipi_csi2_video *video = >video;
> > +   struct v4l2_subdev *subdev = >subdev;
> > +   struct v4l2_async_notifier *notifier = >notifier;
> > +   struct fwnode_handle *handle;
> > +   struct v4l2_fwnode_endpoint *endpoint;
> > +   struct v4l2_async_subdev *subdev_async;
> > +   int ret;
> > +
> > +   /* Subdev */
> > +
> > +   v4l2_subdev_init(subdev, _mipi_csi2_subdev_ops);
> > +   subdev->dev = cdev->dev;
> > +   subdev->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> > +   strscpy(subdev->name, MODULE_NAME, sizeof(subdev->name));
> > +   v4l2_set_subdevdata(subdev, cdev);
> > +
> > +   /* Entity */
> > +
> > +   subdev->entity.function = MEDIA_ENT_F_VID_IF_BRIDGE;
> > +   subdev->entity.ops = _mipi_csi2_entity_ops;
> > +
> > +   /* Pads */
> > +
> > +   video->pads[0].flags = MEDIA_PAD_FL_SINK;
> > +   video->pads[1].flags = MEDIA_PAD_FL_SOURCE;
> > +
> > +   ret = media_entity_pads_init(>entity, 2, video->pads);
> > +   if (ret)
> > +   return ret;
> > +
> > +   /* Endpoint */
> > +
> > +   handle = fwnode_graph_get_endpoint_by_id(dev_fwnode(cdev->dev), 0, 
> > 0,
> > +
> > FWNODE_GRAPH_ENDPOINT_NEXT);
> > +   if (!handle) {
> > +   ret = -ENODEV;
> > +   goto error_media_entity;
> > +   }
> > +
> > +   endpoint = >endpoint;
> > +   endpoint->bus_type = V4L2_MBUS_CSI2_DPHY;
> > +
> > +   ret = v4l2_fwnode_endpoint_parse(handle, endpoint);
> > +   fwnode_handle_put(handle);
> 
> I think the _put should be...
> 
> > +   if (ret)
> > +   goto error_media_entity;
> > +
> > +   /* Notifier */
> > +
> > +   v4l2_async_notifier_init(notifier);
> > +
> > +   subdev_async = >subdev_async;
> > +   ret = v4l2_async_notifier_add_fwnode_remote_subdev(notifier, handle,
> > +  subdev_async);
> 
> ... here. See for instance drivers/media/platform/rcar-vin/rcar-csi2.c.
> 
> (Unless I've missed something, of course).

I think you're right, the reference is obtained at
fwnode_graph_get_endpoint_by_id and should be held when passing handle to
v4l2_async_notifier_add_fwnode_remote_subdev since it will be used to get
a reference to the remote port.

Good catch and thanks for the review!

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH][next] media: i2c: fix spelling mistakes: "enpoint" -> "endpoint"

2021-01-14 Thread Paul Kocialkowski
Hi,

On Wed 13 Jan 21, 10:05, Colin King wrote:
> From: Colin Ian King 
> 
> There are two spelling mistakes in dev_err messages. Fix these.

Thanks for the patch!

Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> Signed-off-by: Colin Ian King 
> ---
>  drivers/media/i2c/ov5648.c | 2 +-
>  drivers/media/i2c/ov8865.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/i2c/ov5648.c b/drivers/media/i2c/ov5648.c
> index 609aa67b54ce..46ad0a539853 100644
> --- a/drivers/media/i2c/ov5648.c
> +++ b/drivers/media/i2c/ov5648.c
> @@ -2453,7 +2453,7 @@ static int ov5648_probe(struct i2c_client *client)
>  
>   handle = fwnode_graph_get_next_endpoint(dev_fwnode(dev), NULL);
>   if (!handle) {
> - dev_err(dev, "unable to find enpoint node\n");
> + dev_err(dev, "unable to find endpoint node\n");
>   return -EINVAL;
>   }
>  
> diff --git a/drivers/media/i2c/ov8865.c b/drivers/media/i2c/ov8865.c
> index fda5a55979aa..fd5be8ef079c 100644
> --- a/drivers/media/i2c/ov8865.c
> +++ b/drivers/media/i2c/ov8865.c
> @@ -2799,7 +2799,7 @@ static int ov8865_probe(struct i2c_client *client)
>  
>   handle = fwnode_graph_get_next_endpoint(dev_fwnode(dev), NULL);
>   if (!handle) {
> - dev_err(dev, "unable to find enpoint node\n");
> + dev_err(dev, "unable to find endpoint node\n");
>   return -EINVAL;
>   }
>  
> -- 
> 2.29.2
> 

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH 5/5] media: hantro: Add support for the Rockchip PX30

2021-01-11 Thread Paul Kocialkowski
Hi,

On Fri 08 Jan 21, 10:13, Ezequiel Garcia wrote:
> On Fri, 2021-01-08 at 10:05 +0100, Paul Kocialkowski wrote:
> > Hi Ezequiel,
> > 
> > On Thu 07 Jan 21, 16:08, Ezequiel Garcia wrote:
> > > Happy to see this patch. It was on my TODO list,
> > > but I hadn't had time to bringup my rk3326 device.
> > 
> > Same here, I just had an occasion to use it again these days so I jumped
> > on it!
> > 
> > > A few comments.
> > > 
> > > On Thu, 2021-01-07 at 14:41 +0100, Paul Kocialkowski wrote:
> > > > The PX30 SoC includes both the VDPU2 and VEPU2 blocks which are similar
> > > > to the RK3399 (Hantro G1/H1 with shuffled registers).
> > > > 
> > > > Besides taking an extra clock, it also shares an interrupt with the 
> > > > IOMMU
> > > > so it's necessary to request the interrupt shared.
> > > > 
> > > 
> [..]
> > > > diff --git a/drivers/staging/media/hantro/hantro_hw.h 
> > > > b/drivers/staging/media/hantro/hantro_hw.h
> > > > index 34c9e4649a25..07f516fd7a2e 100644
> > > > --- a/drivers/staging/media/hantro/hantro_hw.h
> > > > +++ b/drivers/staging/media/hantro/hantro_hw.h
> > > > @@ -148,6 +148,7 @@ enum hantro_enc_fmt {
> > > > RK3288_VPU_ENC_FMT_UYVY422 = 3,
> > > >  };
> > > >  
> > > > +extern const struct hantro_variant px30_vpu_variant;
> > > >  extern const struct hantro_variant rk3399_vpu_variant;
> > > >  extern const struct hantro_variant rk3328_vpu_variant;
> > > >  extern const struct hantro_variant rk3288_vpu_variant;
> > > > diff --git a/drivers/staging/media/hantro/rk3399_vpu_hw.c 
> > > > b/drivers/staging/media/hantro/rk3399_vpu_hw.c
> > > > index 7a7962cf771e..4112f98baa60 100644
> > > > --- a/drivers/staging/media/hantro/rk3399_vpu_hw.c
> > > > +++ b/drivers/staging/media/hantro/rk3399_vpu_hw.c
> > > 
> > > Perhaps it's time to rename this to rockchip_vpu_hw.c,
> > > and merge rk3288 and rk3399? It's a nitpick, though.
> > 
> > Haha, I was thinking the exact same thing but wasn't sure it would be 
> > welcome!
> > 
> > I was thinking of rockchip_vpu2_hw.c or rockchip_vdpu2_hw.c since that's
> > apparently how it's called in Rockchip terminology: VDPU2 and VEPU2 for the
> > Hantro G1 and H1 with the shuffled register layout. The rk3288 stuff is
> > probably VDPU1/VEPU1 and we might want to rename it accordingly as well.
> > 
> 
> I'd rather keep it simple as rockchip_vpu_hw.c and just throw in there
> all the rockchip stuff.

Do you also mean merging all the rk*_vpu_hw.c files into one or just covering
the general helpers (and not the platform-specific structures)?

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH 3/5] dt-bindings: media: rockchip-vpu: Add PX30 compatible

2021-01-11 Thread Paul Kocialkowski
Hi Philipp,

On Thu 07 Jan 21, 15:55, Philipp Zabel wrote:
> Hi Paul,
> 
> On Thu, 2021-01-07 at 14:40 +0100, Paul Kocialkowski wrote:
> > The Rockchip PX30 SoC has a Hantro VPU that features a decoder (VDPU2)
> > and an encoder (VEPU2). It is similar to the RK3399's VPU but takes an
> > extra clock (SCLK).
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  .../bindings/media/rockchip-vpu.yaml  | 25 +--
> >  1 file changed, 17 insertions(+), 8 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml 
> > b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
> > index c81dbc3e8960..c446b9ead21b 100644
> > --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
> > +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
> > @@ -15,10 +15,13 @@ description:
> >  
> >  properties:
> >compatible:
> > -enum:
> > -  - rockchip,rk3288-vpu
> > -  - rockchip,rk3328-vpu
> > -  - rockchip,rk3399-vpu
> > +oneOf:
> > +  - const: rockchip,rk3288-vpu
> > +  - const: rockchip,rk3328-vpu
> > +  - const: rockchip,rk3399-vpu
> > +  - items:
> > +- const: rockchip,px30-vpu
> > +- const: rockchip,rk3399-vpu
> >  
> >reg:
> >  maxItems: 1
> > @@ -35,12 +38,18 @@ properties:
> >- const: vdpu
> >  
> >clocks:
> > -maxItems: 2
> > +minItems: 2
> > +maxItems: 3
> >  
> >clock-names:
> > -items:
> > -  - const: aclk
> > -  - const: hclk
> > +oneOf:
> > +  - items:
> > +- const: aclk
> > +- const: hclk
> > +  - items:
> > +- const: aclk
> > +- const: hclk
> > +- const: sclk
> 
> You could make this:
> 
> clock-names:
>   minItems: 2
>   items:
> - const: aclk
> - const: hclk
> - const: sclk
> 
> And then:
> 
> allOf:
>   - if:
>   properties:
> compatible:
>   contains:
> const: rockchip,px30-vpu
> then:
>   properties:
> clock-names:
>   minItems: 3
> 
> to make sure each variant has the correct clocks set.

Thanks for the suggestion! That's a finer grain that my proposal.

Rob, is there a preference for how this case should be handled?
Here, we want to specify an extra clock for the PX30 case.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH v4 09/15] media: sunxi: Add support for the A31 MIPI CSI-2 controller

2021-01-11 Thread Paul Kocialkowski
Hi Samuel,

On Sat 09 Jan 21, 16:24, Samuel Holland wrote:
> On 12/31/20 8:29 AM, Paul Kocialkowski wrote:
> > The A31 MIPI CSI-2 controller is a dedicated MIPI CSI-2 bridge
> > found on Allwinner SoCs such as the A31 and V3/V3s.
> > 
> > It is a standalone block, connected to the CSI controller on one side
> > and to the MIPI D-PHY block on the other. It has a dedicated address
> > space, interrupt line and clock.
> > 
> > It is represented as a V4L2 subdev to the CSI controller and takes a
> > MIPI CSI-2 sensor as its own subdev, all using the fwnode graph and
> > media controller API.
> > 
> > Only 8-bit and 10-bit Bayer formats are currently supported.
> > While up to 4 internal channels to the CSI controller exist, only one
> > is currently supported by this implementation.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  drivers/media/platform/sunxi/Kconfig  |   1 +
> >  drivers/media/platform/sunxi/Makefile |   1 +
> >  .../platform/sunxi/sun6i-mipi-csi2/Kconfig|  12 +
> >  .../platform/sunxi/sun6i-mipi-csi2/Makefile   |   4 +
> >  .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c   | 590 ++
> >  .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h   | 117 
> >  6 files changed, 725 insertions(+)
> >  create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
> >  create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
> >  create mode 100644 
> > drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
> >  create mode 100644 
> > drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h
> > 
> > diff --git a/drivers/media/platform/sunxi/Kconfig 
> > b/drivers/media/platform/sunxi/Kconfig
> > index 7151cc249afa..9684e07454ad 100644
> > --- a/drivers/media/platform/sunxi/Kconfig
> > +++ b/drivers/media/platform/sunxi/Kconfig
> > @@ -2,3 +2,4 @@
> >  
> >  source "drivers/media/platform/sunxi/sun4i-csi/Kconfig"
> >  source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
> > +source "drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig"
> > diff --git a/drivers/media/platform/sunxi/Makefile 
> > b/drivers/media/platform/sunxi/Makefile
> > index fc537c9f5ca9..887a7cae8fca 100644
> > --- a/drivers/media/platform/sunxi/Makefile
> > +++ b/drivers/media/platform/sunxi/Makefile
> > @@ -2,5 +2,6 @@
> >  
> >  obj-y  += sun4i-csi/
> >  obj-y  += sun6i-csi/
> > +obj-y  += sun6i-mipi-csi2/
> >  obj-y  += sun8i-di/
> >  obj-y  += sun8i-rotate/
> > diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig 
> > b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
> > new file mode 100644
> > index ..47f1bb0779a8
> > --- /dev/null
> > +++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
> > @@ -0,0 +1,12 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +config VIDEO_SUN6I_MIPI_CSI2
> > +   tristate "Allwinner A31 MIPI CSI-2 Controller Driver"
> > +   depends on ARCH_SUNXI || COMPILE_TEST
> > +   depends on PM && COMMON_CLK && VIDEO_V4L2
> > +   select REGMAP_MMIO
> > +   select PHY_SUN6I_MIPI_DPHY
> > +   select MEDIA_CONTROLLER
> > +   select VIDEO_V4L2_SUBDEV_API
> > +   select V4L2_FWNODE
> > +   help
> > +  Support for the Allwinner A31 MIPI CSI-2 Controller.
> > diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile 
> > b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
> > new file mode 100644
> > index ..14e4e03818b5
> > --- /dev/null
> > +++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
> > @@ -0,0 +1,4 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +sun6i-mipi-csi2-y += sun6i_mipi_csi2.o
> > +
> > +obj-$(CONFIG_VIDEO_SUN6I_MIPI_CSI2) += sun6i-mipi-csi2.o
> > diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c 
> > b/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
> > new file mode 100644
> > index ..87307beda4cf
> > --- /dev/null
> > +++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
> > @@ -0,0 +1,590 @@
> [...]
> > +/* Base Driver */
> > +
> > +static int sun6i_mipi_csi2_suspend(struct device *dev)
> > +{
> > +   struct sun6i_mipi_csi2_dev *cdev = dev_get_drvdata(dev);
> > +
> > +   clk_disable_unprepare(cdev->clk_mod);
> > +   clk_disable_unprepare(cdev->clk_bus);
> >

Re: [PATCH 5/5] media: hantro: Add support for the Rockchip PX30

2021-01-08 Thread Paul Kocialkowski
Hi Ezequiel,

On Thu 07 Jan 21, 16:08, Ezequiel Garcia wrote:
> Happy to see this patch. It was on my TODO list,
> but I hadn't had time to bringup my rk3326 device.

Same here, I just had an occasion to use it again these days so I jumped
on it!

> A few comments.
> 
> On Thu, 2021-01-07 at 14:41 +0100, Paul Kocialkowski wrote:
> > The PX30 SoC includes both the VDPU2 and VEPU2 blocks which are similar
> > to the RK3399 (Hantro G1/H1 with shuffled registers).
> > 
> > Besides taking an extra clock, it also shares an interrupt with the IOMMU
> > so it's necessary to request the interrupt shared.
> > 
> 
> Could you clarify on the commit description which iommu device interrupt
> line is being shared?

Sure! It's IRQ 79 of the GIC that's shared with vopl_mmu.
It's not very obvious in the dt commit.

> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  drivers/staging/media/hantro/hantro_drv.c    |  5 +++--
> >  drivers/staging/media/hantro/hantro_hw.h |  1 +
> >  drivers/staging/media/hantro/rk3399_vpu_hw.c | 21 
> >  3 files changed, 25 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/staging/media/hantro/hantro_drv.c 
> > b/drivers/staging/media/hantro/hantro_drv.c
> > index e5f200e64993..076a7782b476 100644
> > --- a/drivers/staging/media/hantro/hantro_drv.c
> > +++ b/drivers/staging/media/hantro/hantro_drv.c
> > @@ -472,6 +472,7 @@ static const struct v4l2_file_operations hantro_fops = {
> >  
> >  static const struct of_device_id of_hantro_match[] = {
> >  #ifdef CONFIG_VIDEO_HANTRO_ROCKCHIP
> > +   { .compatible = "rockchip,px30-vpu", .data = _vpu_variant, },
> > { .compatible = "rockchip,rk3399-vpu", .data = _vpu_variant, 
> > },
> > { .compatible = "rockchip,rk3328-vpu", .data = _vpu_variant, 
> > },
> > { .compatible = "rockchip,rk3288-vpu", .data = _vpu_variant, 
> > },
> > @@ -796,8 +797,8 @@ static int hantro_probe(struct platform_device *pdev)
> > return -ENXIO;
> >  
> > ret = devm_request_irq(vpu->dev, irq,
> > -  vpu->variant->irqs[i].handler, 0,
> > -  dev_name(vpu->dev), vpu);
> > +  vpu->variant->irqs[i].handler,
> > +  IRQF_SHARED, dev_name(vpu->dev), 
> > vpu);
> 
> Maybe this irq flag should be part of vpu->variant? It sounds like an IP block
> integration specific thing.

Ah right, I agree that it would be justified. But it would also be simple to
just fix the irq handlers and assume this can generally be the case, because it
feels like a bit of a detail to justify a flag.

Do you think this could be a safe/workable assumption?

> Also, you will need a px30-specific interrupt handler now,
> since the rk3399 one is not shared-friendly.

Yeah I realize I haven't been very careful there and didn't really check that
the IOMMU driver is really safe to handle shared interrupts either. I'll take
a look a that when crafting v2.

> > if (ret) {
> > dev_err(vpu->dev, "Could not request %s IRQ.\n",
> > irq_name);
> > diff --git a/drivers/staging/media/hantro/hantro_hw.h 
> > b/drivers/staging/media/hantro/hantro_hw.h
> > index 34c9e4649a25..07f516fd7a2e 100644
> > --- a/drivers/staging/media/hantro/hantro_hw.h
> > +++ b/drivers/staging/media/hantro/hantro_hw.h
> > @@ -148,6 +148,7 @@ enum hantro_enc_fmt {
> > RK3288_VPU_ENC_FMT_UYVY422 = 3,
> >  };
> >  
> > +extern const struct hantro_variant px30_vpu_variant;
> >  extern const struct hantro_variant rk3399_vpu_variant;
> >  extern const struct hantro_variant rk3328_vpu_variant;
> >  extern const struct hantro_variant rk3288_vpu_variant;
> > diff --git a/drivers/staging/media/hantro/rk3399_vpu_hw.c 
> > b/drivers/staging/media/hantro/rk3399_vpu_hw.c
> > index 7a7962cf771e..4112f98baa60 100644
> > --- a/drivers/staging/media/hantro/rk3399_vpu_hw.c
> > +++ b/drivers/staging/media/hantro/rk3399_vpu_hw.c
> 
> Perhaps it's time to rename this to rockchip_vpu_hw.c,
> and merge rk3288 and rk3399? It's a nitpick, though.

Haha, I was thinking the exact same thing but wasn't sure it would be welcome!

I was thinking of rockchip_vpu2_hw.c or rockchip_vdpu2_hw.c since that's
apparently how it's called in Rockchip terminology: VDPU2 and VEPU2 for the
Hantro G1 and H1 with the shuffled register layout. The rk3288 stuff is
probably VDPU1/VEPU1 and we migh

Re: [PATCH 2/5] arm64: dts: rockchip: Add RGA support to the PX30

2021-01-07 Thread Paul Kocialkowski
On Thu 07 Jan 21, 14:40, Paul Kocialkowski wrote:
> The PX30 features a RGA block: add the necessary node to support it.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  arch/arm64/boot/dts/rockchip/px30.dtsi | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi 
> b/arch/arm64/boot/dts/rockchip/px30.dtsi
> index 2695ea8cda14..e056d1c32cc8 100644
> --- a/arch/arm64/boot/dts/rockchip/px30.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
> @@ -1106,6 +1106,17 @@ vopl_mmu: iommu@ff470f00 {
>   status = "disabled";
>   };
>  
> + rga: rga@ff48 {
> + compatible = "rockchip,px30-rga", "rockchip,rk3288-rga";
> + reg = <0x0 0xff48 0x0 0x1>;
> + interrupts = ;

Looks like this trailing 0 shouldn't be here. Will fix in v2.

Cheers,

Paul

> + clocks = < ACLK_RGA>, < HCLK_RGA>, < SCLK_RGA_CORE>;
> + clock-names = "aclk", "hclk", "sclk";
> + power-domains = < PX30_PD_VO>;
> + resets = < SRST_RGA>, < SRST_RGA_A>, < SRST_RGA_H>;
> + reset-names = "core", "axi", "ahb";
> + };
> +
>   qos_gmac: qos@ff518000 {
>   compatible = "syscon";
>   reg = <0x0 0xff518000 0x0 0x20>;
> -- 
> 2.30.0
> 

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


[PATCH 3/5] dt-bindings: media: rockchip-vpu: Add PX30 compatible

2021-01-07 Thread Paul Kocialkowski
The Rockchip PX30 SoC has a Hantro VPU that features a decoder (VDPU2)
and an encoder (VEPU2). It is similar to the RK3399's VPU but takes an
extra clock (SCLK).

Signed-off-by: Paul Kocialkowski 
---
 .../bindings/media/rockchip-vpu.yaml  | 25 +--
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml 
b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
index c81dbc3e8960..c446b9ead21b 100644
--- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
@@ -15,10 +15,13 @@ description:
 
 properties:
   compatible:
-enum:
-  - rockchip,rk3288-vpu
-  - rockchip,rk3328-vpu
-  - rockchip,rk3399-vpu
+oneOf:
+  - const: rockchip,rk3288-vpu
+  - const: rockchip,rk3328-vpu
+  - const: rockchip,rk3399-vpu
+  - items:
+- const: rockchip,px30-vpu
+- const: rockchip,rk3399-vpu
 
   reg:
 maxItems: 1
@@ -35,12 +38,18 @@ properties:
   - const: vdpu
 
   clocks:
-maxItems: 2
+minItems: 2
+maxItems: 3
 
   clock-names:
-items:
-  - const: aclk
-  - const: hclk
+oneOf:
+  - items:
+- const: aclk
+- const: hclk
+  - items:
+- const: aclk
+- const: hclk
+- const: sclk
 
   power-domains:
 maxItems: 1
-- 
2.30.0



[PATCH 4/5] arm64: dts: rockchip: Add VPU support for the PX30

2021-01-07 Thread Paul Kocialkowski
The PX30 has a VPU (both decoder and encoder) with a dedicated IOMMU.
Describe these two entities in device-tree.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm64/boot/dts/rockchip/px30.dtsi | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi 
b/arch/arm64/boot/dts/rockchip/px30.dtsi
index e056d1c32cc8..4322302a2685 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -986,6 +986,29 @@ gpu: gpu@ff40 {
status = "disabled";
};
 
+   vpu: video-codec@ff442000 {
+   compatible = "rockchip,px30-vpu", "rockchip,rk3399-vpu";
+   reg = <0x0 0xff442000 0x0 0x800>;
+   interrupts = ,
+;
+   interrupt-names = "vepu", "vdpu";
+   clocks = < ACLK_VPU>, < HCLK_VPU>, < SCLK_CORE_VPU>;
+   clock-names = "aclk", "hclk", "sclk";
+   iommus = <_mmu>;
+   power-domains = < PX30_PD_VPU>;
+   };
+
+   vpu_mmu: iommu@ff442800 {
+   compatible = "rockchip,iommu";
+   reg = <0x0 0xff442800 0x0 0x100>;
+   interrupts = ;
+   interrupt-names = "vpu_mmu";
+   clocks = < ACLK_VPU>, < HCLK_VPU>;
+   clock-names = "aclk", "iface";
+   #iommu-cells = <0>;
+   power-domains = < PX30_PD_VPU>;
+   };
+
dsi: dsi@ff45 {
compatible = "rockchip,px30-mipi-dsi";
reg = <0x0 0xff45 0x0 0x1>;
-- 
2.30.0



[PATCH 5/5] media: hantro: Add support for the Rockchip PX30

2021-01-07 Thread Paul Kocialkowski
The PX30 SoC includes both the VDPU2 and VEPU2 blocks which are similar
to the RK3399 (Hantro G1/H1 with shuffled registers).

Besides taking an extra clock, it also shares an interrupt with the IOMMU
so it's necessary to request the interrupt shared.

Signed-off-by: Paul Kocialkowski 
---
 drivers/staging/media/hantro/hantro_drv.c|  5 +++--
 drivers/staging/media/hantro/hantro_hw.h |  1 +
 drivers/staging/media/hantro/rk3399_vpu_hw.c | 21 
 3 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro_drv.c 
b/drivers/staging/media/hantro/hantro_drv.c
index e5f200e64993..076a7782b476 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -472,6 +472,7 @@ static const struct v4l2_file_operations hantro_fops = {
 
 static const struct of_device_id of_hantro_match[] = {
 #ifdef CONFIG_VIDEO_HANTRO_ROCKCHIP
+   { .compatible = "rockchip,px30-vpu", .data = _vpu_variant, },
{ .compatible = "rockchip,rk3399-vpu", .data = _vpu_variant, },
{ .compatible = "rockchip,rk3328-vpu", .data = _vpu_variant, },
{ .compatible = "rockchip,rk3288-vpu", .data = _vpu_variant, },
@@ -796,8 +797,8 @@ static int hantro_probe(struct platform_device *pdev)
return -ENXIO;
 
ret = devm_request_irq(vpu->dev, irq,
-  vpu->variant->irqs[i].handler, 0,
-  dev_name(vpu->dev), vpu);
+  vpu->variant->irqs[i].handler,
+  IRQF_SHARED, dev_name(vpu->dev), vpu);
if (ret) {
dev_err(vpu->dev, "Could not request %s IRQ.\n",
irq_name);
diff --git a/drivers/staging/media/hantro/hantro_hw.h 
b/drivers/staging/media/hantro/hantro_hw.h
index 34c9e4649a25..07f516fd7a2e 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -148,6 +148,7 @@ enum hantro_enc_fmt {
RK3288_VPU_ENC_FMT_UYVY422 = 3,
 };
 
+extern const struct hantro_variant px30_vpu_variant;
 extern const struct hantro_variant rk3399_vpu_variant;
 extern const struct hantro_variant rk3328_vpu_variant;
 extern const struct hantro_variant rk3288_vpu_variant;
diff --git a/drivers/staging/media/hantro/rk3399_vpu_hw.c 
b/drivers/staging/media/hantro/rk3399_vpu_hw.c
index 7a7962cf771e..4112f98baa60 100644
--- a/drivers/staging/media/hantro/rk3399_vpu_hw.c
+++ b/drivers/staging/media/hantro/rk3399_vpu_hw.c
@@ -220,3 +220,24 @@ const struct hantro_variant rk3328_vpu_variant = {
.clk_names = rk3399_clk_names,
.num_clocks = ARRAY_SIZE(rk3399_clk_names),
 };
+
+static const char * const px30_clk_names[] = {
+   "aclk", "hclk", "sclk"
+};
+
+const struct hantro_variant px30_vpu_variant = {
+   .enc_offset = 0x0,
+   .enc_fmts = rk3399_vpu_enc_fmts,
+   .num_enc_fmts = ARRAY_SIZE(rk3399_vpu_enc_fmts),
+   .dec_offset = 0x400,
+   .dec_fmts = rk3399_vpu_dec_fmts,
+   .num_dec_fmts = ARRAY_SIZE(rk3399_vpu_dec_fmts),
+   .codec = HANTRO_JPEG_ENCODER | HANTRO_MPEG2_DECODER |
+HANTRO_VP8_DECODER,
+   .codec_ops = rk3399_vpu_codec_ops,
+   .irqs = rk3399_irqs,
+   .num_irqs = ARRAY_SIZE(rk3399_irqs),
+   .init = rk3399_vpu_hw_init,
+   .clk_names = px30_clk_names,
+   .num_clocks = ARRAY_SIZE(px30_clk_names)
+};
-- 
2.30.0



[PATCH 0/5] Rockchip PX30 RGA and VPU support

2021-01-07 Thread Paul Kocialkowski
This series adds the required bits for RGA and VPU support on the
Rockchip PX30 SoC.

Cheers,

Paul

Paul Kocialkowski (5):
  dt-bindings: media: rockchip-rga: Add PX30 compatible
  arm64: dts: rockchip: Add RGA support to the PX30
  dt-bindings: media: rockchip-vpu: Add PX30 compatible
  arm64: dts: rockchip: Add VPU support for the PX30
  media: hantro: Add support for the Rockchip PX30

 .../bindings/media/rockchip-rga.yaml  |  4 ++-
 .../bindings/media/rockchip-vpu.yaml  | 25 +-
 arch/arm64/boot/dts/rockchip/px30.dtsi| 34 +++
 drivers/staging/media/hantro/hantro_drv.c |  5 +--
 drivers/staging/media/hantro/hantro_hw.h  |  1 +
 drivers/staging/media/hantro/rk3399_vpu_hw.c  | 21 
 6 files changed, 79 insertions(+), 11 deletions(-)

-- 
2.30.0



[PATCH 2/5] arm64: dts: rockchip: Add RGA support to the PX30

2021-01-07 Thread Paul Kocialkowski
The PX30 features a RGA block: add the necessary node to support it.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm64/boot/dts/rockchip/px30.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi 
b/arch/arm64/boot/dts/rockchip/px30.dtsi
index 2695ea8cda14..e056d1c32cc8 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -1106,6 +1106,17 @@ vopl_mmu: iommu@ff470f00 {
status = "disabled";
};
 
+   rga: rga@ff48 {
+   compatible = "rockchip,px30-rga", "rockchip,rk3288-rga";
+   reg = <0x0 0xff48 0x0 0x1>;
+   interrupts = ;
+   clocks = < ACLK_RGA>, < HCLK_RGA>, < SCLK_RGA_CORE>;
+   clock-names = "aclk", "hclk", "sclk";
+   power-domains = < PX30_PD_VO>;
+   resets = < SRST_RGA>, < SRST_RGA_A>, < SRST_RGA_H>;
+   reset-names = "core", "axi", "ahb";
+   };
+
qos_gmac: qos@ff518000 {
compatible = "syscon";
reg = <0x0 0xff518000 0x0 0x20>;
-- 
2.30.0



[PATCH 1/5] dt-bindings: media: rockchip-rga: Add PX30 compatible

2021-01-07 Thread Paul Kocialkowski
Add a new compatible for the PX30 Rockchip SoC, which also features
a RGA block. It is compatible with the RK3288 RGA block.

Signed-off-by: Paul Kocialkowski 
---
 Documentation/devicetree/bindings/media/rockchip-rga.yaml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/media/rockchip-rga.yaml 
b/Documentation/devicetree/bindings/media/rockchip-rga.yaml
index dd645ddccb07..4ffdb317b606 100644
--- a/Documentation/devicetree/bindings/media/rockchip-rga.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip-rga.yaml
@@ -21,7 +21,9 @@ properties:
   - const: rockchip,rk3288-rga
   - const: rockchip,rk3399-rga
   - items:
-  - const: rockchip,rk3228-rga
+  - enum:
+- rockchip,px30-rga
+- rockchip,rk3228-rga
   - const: rockchip,rk3288-rga
 
   reg:
-- 
2.30.0



Re: [PATCH v8 4/4] NOTFORMERGE: drm/logicvc: Add plane colorkey support

2021-01-05 Thread Paul Kocialkowski
Hi,

On Wed 23 Dec 20, 18:31, Ilia Mirkin wrote:
> FWIW this is something I added, hoping it was going to get used at
> some point, but I never followed up with support in xf86-video-nouveau
> for Xv. At this point, I'm not sure I ever will. I encoded the
> "enabled" part into the value with a high bit (1<<24) -- not sure that
> was such a great idea. All NVIDIA hardware supports colorkey (and not
> actual alpha, until the very latest GPUs - Volta/Turing families),
> although my implementation only covers the pre-G80 series (i.e. DX9
> and earlier GPUs - pre-2008). Should a determination of usefulness be
> reached, it would be easy to implement on the remainder though.

Interesting to know!

Regarding a generic colorkey property, there was a discussion under thread:
drm: Add generic colorkey properties for display planes

and the latest proposal (RFC v4) can be found here:
https://patchwork.ozlabs.org/project/linux-tegra/patch/20180807172202.1961-2-dig...@gmail.com/

It looks like this was much more complex than anticipated and the series
was more or less abandonned. I didn't feel like picking it up in my logicvc
series so I kept the colorkey patch as not for merge.

If someone's up for picking the proposal and continuing the discussion,
I could provide insight on how it would fit with logicvc though!

Cheers,

Paul

> On Wed, Dec 23, 2020 at 5:20 PM Simon Ser  wrote:
> >
> > nouveau already has something for colorkey:
> > https://drmdb.emersion.fr/properties/4008636142/colorkey
> >
> > I know this is marked "not for merge", but it would be nice to discuss
> > with them and come up with a standardized property.

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH v4 2/3] media: i2c: Add support for the OV8865 image sensor

2021-01-05 Thread Paul Kocialkowski
Hi Sakari,

On Tue 05 Jan 21, 16:41, Sakari Ailus wrote:
> Hi Paul,
> 
> On Tue, Jan 05, 2021 at 10:38:47AM +0100, Paul Kocialkowski wrote:
> > Hi Sakari,
> > 
> > On Mon 04 Jan 21, 14:07, Sakari Ailus wrote:
> > > Hi Paul,
> > > 
> > > On Thu, Dec 31, 2020 at 03:27:01PM +0100, Paul Kocialkowski wrote:
> > > > The OV8865 is a 8 Mpx CMOS image sensor producing 3264x2448 at 30 fps.
> > > > Other modes (including some with sub-sampling) are available too.
> > > > It outputs 10-bit bayer CFA data through a MIPI CSI-2 interface with
> > > > up to 4 lanes supported.
> > > 
> > > I've added the patches to a pull request to Mauro; there appear to still 
> > > be
> > > some checkpatch.pl issues in both of the drivers.
> > > 
> > > I don't mind the warnings on the assignment or the mutex though. Could you
> > > address these in additional patches, please?
> > 
> > Sorry about that, I realized that I never run checkpatch with --strict
> > so I completely missed those.
> > 
> > I'll fix the cosmetic issues in a following patch.
> > 
> > Just to clarify one thing:
> > #define OV8865_PAD_PK_DRIVE_STRENGTH_2X (1 << 5)
> > #define OV8865_BLC_CTRL1_COL_SHIFT_128  (1 << 4)
> > 
> > these are not single-bit fields so even though it looks like they should
> > use BIT(), this would be incoherent with other possible values, such as:
> > #define OV8865_PAD_PK_DRIVE_STRENGTH_3X (2 << 5)
> > #define OV8865_BLC_CTRL1_COL_SHIFT_64   (2 << 4)
> 
> Agreed.
> 
> You might not assign the top bit, but if you did, the left operand would
> have to be unsigned to guarantee the intended result (otherwise it's
> undefined).

Ah right, that's the issue with shifting signed constants up to the sign bit.
I had a quick look and I think this driver's safe about it.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


[PATCH v2] media: i2c: ov5648/ov8865: Minor cosmetic fixes

2021-01-05 Thread Paul Kocialkowski
This solves a few minor cosmetic issues picked up by checkpatch for
the OV5648 and OV8865 drivers.

Signed-off-by: Paul Kocialkowski 
---
 drivers/media/i2c/ov5648.c | 3 ++-
 drivers/media/i2c/ov8865.c | 8 
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/media/i2c/ov5648.c b/drivers/media/i2c/ov5648.c
index 609aa67b54ce..110190b322e2 100644
--- a/drivers/media/i2c/ov5648.c
+++ b/drivers/media/i2c/ov5648.c
@@ -496,7 +496,8 @@
container_of(s, struct ov5648_sensor, subdev)
 
 #define ov5648_ctrl_subdev(c) \
-   (_of(c->handler, struct ov5648_sensor, ctrls.handler)->subdev)
+   (_of((c)->handler, struct ov5648_sensor, \
+  ctrls.handler)->subdev)
 
 /* Data structures */
 
diff --git a/drivers/media/i2c/ov8865.c b/drivers/media/i2c/ov8865.c
index fda5a55979aa..ab4804d5b285 100644
--- a/drivers/media/i2c/ov8865.c
+++ b/drivers/media/i2c/ov8865.c
@@ -223,7 +223,6 @@
 #define OV8865_FORMAT2_FLIP_HORZ_SENSOR_EN BIT(1)
 #define OV8865_FORMAT2_SYNC_HBIN_ENBIT(0)
 
-
 #define OV8865_INC_Y_ODD_REG   0x382a
 #define OV8865_INC_Y_ODD(v)((v) & GENMASK(4, 0))
 #define OV8865_INC_Y_EVEN_REG  0x382b
@@ -460,7 +459,8 @@
container_of(s, struct ov8865_sensor, subdev)
 
 #define ov8865_ctrl_subdev(c) \
-   (_of(c->handler, struct ov8865_sensor, ctrls.handler)->subdev)
+   (_of((c)->handler, struct ov8865_sensor, \
+  ctrls.handler)->subdev)
 
 /* Data structures */
 
@@ -1598,8 +1598,8 @@ static int ov8865_mode_pll1_configure(struct 
ov8865_sensor *sensor,
return ret;
 
ret = ov8865_update_bits(sensor, OV8865_PCLK_SEL_REG,
-  OV8865_PCLK_SEL_PCLK_DIV_MASK,
-  OV8865_PCLK_SEL_PCLK_DIV(config->pclk_div));
+OV8865_PCLK_SEL_PCLK_DIV_MASK,
+OV8865_PCLK_SEL_PCLK_DIV(config->pclk_div));
if (ret)
return ret;
 
-- 
2.30.0



Re: [PATCH v4 2/3] media: i2c: Add support for the OV8865 image sensor

2021-01-05 Thread Paul Kocialkowski
Hi Sakari,

On Mon 04 Jan 21, 14:07, Sakari Ailus wrote:
> Hi Paul,
> 
> On Thu, Dec 31, 2020 at 03:27:01PM +0100, Paul Kocialkowski wrote:
> > The OV8865 is a 8 Mpx CMOS image sensor producing 3264x2448 at 30 fps.
> > Other modes (including some with sub-sampling) are available too.
> > It outputs 10-bit bayer CFA data through a MIPI CSI-2 interface with
> > up to 4 lanes supported.
> 
> I've added the patches to a pull request to Mauro; there appear to still be
> some checkpatch.pl issues in both of the drivers.
> 
> I don't mind the warnings on the assignment or the mutex though. Could you
> address these in additional patches, please?

Sorry about that, I realized that I never run checkpatch with --strict
so I completely missed those.

I'll fix the cosmetic issues in a following patch.

Just to clarify one thing:
#define OV8865_PAD_PK_DRIVE_STRENGTH_2X (1 << 5)
#define OV8865_BLC_CTRL1_COL_SHIFT_128  (1 << 4)

these are not single-bit fields so even though it looks like they should
use BIT(), this would be incoherent with other possible values, such as:
#define OV8865_PAD_PK_DRIVE_STRENGTH_3X (2 << 5)
#define OV8865_BLC_CTRL1_COL_SHIFT_64   (2 << 4)

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


[PATCH] media: i2c: ov5648/ov8865: Minor cosmetic fixes

2021-01-05 Thread Paul Kocialkowski
This solves a few minor cosmetic issues picked up by checkpatch for
the OV5648 and OV8865 drivers.

Signed-off-by: Paul Kocialkowski 
---
 drivers/media/i2c/ov5648.c | 2 +-
 drivers/media/i2c/ov8865.c | 7 +++
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/media/i2c/ov5648.c b/drivers/media/i2c/ov5648.c
index 609aa67b54ce..752a2e035c49 100644
--- a/drivers/media/i2c/ov5648.c
+++ b/drivers/media/i2c/ov5648.c
@@ -496,7 +496,7 @@
container_of(s, struct ov5648_sensor, subdev)
 
 #define ov5648_ctrl_subdev(c) \
-   (_of(c->handler, struct ov5648_sensor, ctrls.handler)->subdev)
+   (_of((c)->handler, struct ov5648_sensor, 
ctrls.handler)->subdev)
 
 /* Data structures */
 
diff --git a/drivers/media/i2c/ov8865.c b/drivers/media/i2c/ov8865.c
index fda5a55979aa..704d75b601e3 100644
--- a/drivers/media/i2c/ov8865.c
+++ b/drivers/media/i2c/ov8865.c
@@ -223,7 +223,6 @@
 #define OV8865_FORMAT2_FLIP_HORZ_SENSOR_EN BIT(1)
 #define OV8865_FORMAT2_SYNC_HBIN_ENBIT(0)
 
-
 #define OV8865_INC_Y_ODD_REG   0x382a
 #define OV8865_INC_Y_ODD(v)((v) & GENMASK(4, 0))
 #define OV8865_INC_Y_EVEN_REG  0x382b
@@ -460,7 +459,7 @@
container_of(s, struct ov8865_sensor, subdev)
 
 #define ov8865_ctrl_subdev(c) \
-   (_of(c->handler, struct ov8865_sensor, ctrls.handler)->subdev)
+   (_of((c)->handler, struct ov8865_sensor, 
ctrls.handler)->subdev)
 
 /* Data structures */
 
@@ -1598,8 +1597,8 @@ static int ov8865_mode_pll1_configure(struct 
ov8865_sensor *sensor,
return ret;
 
ret = ov8865_update_bits(sensor, OV8865_PCLK_SEL_REG,
-  OV8865_PCLK_SEL_PCLK_DIV_MASK,
-  OV8865_PCLK_SEL_PCLK_DIV(config->pclk_div));
+OV8865_PCLK_SEL_PCLK_DIV_MASK,
+OV8865_PCLK_SEL_PCLK_DIV(config->pclk_div));
if (ret)
return ret;
 
-- 
2.29.2



[PATCH v4 10/15] ARM: dts: sun8i: v3s: Add nodes for MIPI CSI-2 support

2020-12-31 Thread Paul Kocialkowski
MIPI CSI-2 is supported on the V3s with an A31-based MIPI CSI-2 bridge
controller. The controller uses a separate D-PHY, which is the same
that is otherwise used for MIPI DSI, but used in Rx mode.

On the V3s, the CSI0 controller is dedicated to MIPI CSI-2 as it does
not have access to any parallel interface pins.

Add all the necessary nodes (CSI0, MIPI CSI-2 bridge and D-PHY) to
support the MIPI CSI-2 interface.

Note that a fwnode graph link is created between CSI0 and MIPI CSI-2
even when no sensor is connected. This will result in a probe failure
for the controller as long as no sensor is connected but this is fine
since no other interface is available.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun8i-v3s.dtsi | 67 
 1 file changed, 67 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 7b2d684aeb97..b7f2bcd25c86 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -530,6 +530,31 @@ spi0: spi@1c68000 {
#size-cells = <0>;
};
 
+   csi0: camera@1cb {
+   compatible = "allwinner,sun8i-v3s-csi";
+   reg = <0x01cb 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_CSI>,
+< CLK_CSI1_SCLK>,
+< CLK_DRAM_CSI>;
+   clock-names = "bus", "mod", "ram";
+   resets = < RST_BUS_CSI>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+
+   csi0_in_mipi_csi2: endpoint {
+   remote-endpoint = 
<_csi2_out_csi0>;
+   };
+   };
+   };
+   };
+
csi1: camera@1cb4000 {
compatible = "allwinner,sun8i-v3s-csi";
reg = <0x01cb4000 0x3000>;
@@ -552,5 +577,47 @@ gic: interrupt-controller@1c81000 {
#interrupt-cells = <3>;
interrupts = ;
};
+
+   mipi_csi2: csi@1cb1000 {
+   compatible = "allwinner,sun8i-v3s-mipi-csi2",
+"allwinner,sun6i-a31-mipi-csi2";
+   reg = <0x01cb1000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_CSI>,
+< CLK_CSI1_SCLK>;
+   clock-names = "bus", "mod";
+   resets = < RST_BUS_CSI>;
+   status = "disabled";
+
+   phys = <>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mipi_csi2_in: port@0 {
+   reg = <0>;
+   };
+
+   mipi_csi2_out: port@1 {
+   reg = <1>;
+
+   mipi_csi2_out_csi0: endpoint {
+   remote-endpoint = 
<_in_mipi_csi2>;
+   };
+   };
+   };
+   };
+
+   dphy: d-phy@1cb2000 {
+   compatible = "allwinner,sun6i-a31-mipi-dphy";
+   reg = <0x01cb2000 0x1000>;
+   clocks = < CLK_BUS_CSI>,
+< CLK_MIPI_CSI>;
+   clock-names = "bus", "mod";
+   resets = < RST_BUS_CSI>;
+   status = "disabled";
+   #phy-cells = <0>;
+   };
};
 };
-- 
2.29.2



[PATCH v4 12/15] dt-bindings: media: Add A83T MIPI CSI-2 bindings documentation

2020-12-31 Thread Paul Kocialkowski
This introduces YAML bindings documentation for the A83T MIPI CSI-2
controller.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Rob Herring 
---
 .../media/allwinner,sun8i-a83t-mipi-csi2.yaml | 147 ++
 1 file changed, 147 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml

diff --git 
a/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml 
b/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml
new file mode 100644
index ..e607fae7d85e
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml
@@ -0,0 +1,147 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/allwinner,sun8i-a83t-mipi-csi2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A83T MIPI CSI-2 Device Tree Bindings
+
+maintainers:
+  - Paul Kocialkowski 
+
+properties:
+  compatible:
+const: allwinner,sun8i-a83t-mipi-csi2
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+items:
+  - description: Bus Clock
+  - description: Module Clock
+  - description: MIPI-specific Clock
+  - description: Misc CSI Clock
+
+  clock-names:
+items:
+  - const: bus
+  - const: mod
+  - const: mipi
+  - const: misc
+
+  resets:
+maxItems: 1
+
+  # See ./video-interfaces.txt for details
+  ports:
+type: object
+
+properties:
+  port@0:
+type: object
+description: Input port, connect to a MIPI CSI-2 sensor
+
+properties:
+  reg:
+const: 0
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+  clock-lanes:
+maxItems: 1
+
+  data-lanes:
+minItems: 1
+maxItems: 4
+
+required:
+  - data-lanes
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
+  port@1:
+type: object
+description: Output port, connect to a CSI controller
+
+properties:
+  reg:
+const: 1
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+required:
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - resets
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+
+mipi_csi2: csi@1cb1000 {
+compatible = "allwinner,sun8i-a83t-mipi-csi2";
+reg = <0x01cb1000 0x1000>;
+interrupts = ;
+clocks = < CLK_BUS_CSI>,
+ < CLK_CSI_SCLK>,
+ < CLK_MIPI_CSI>,
+ < CLK_CSI_MISC>;
+clock-names = "bus", "mod", "mipi", "misc";
+resets = < RST_BUS_CSI>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+mipi_csi2_in: port@0 {
+reg = <0>;
+
+mipi_csi2_in_ov8865: endpoint {
+data-lanes = <1 2 3 4>;
+
+remote-endpoint = <_out_mipi_csi2>;
+};
+};
+
+mipi_csi2_out: port@1 {
+reg = <1>;
+
+mipi_csi2_out_csi: endpoint {
+remote-endpoint = <_in_mipi_csi2>;
+};
+};
+};
+};
+
+...
-- 
2.29.2



[PATCH v4 05/15] media: sun6i-csi: Only configure the interface data width for parallel

2020-12-31 Thread Paul Kocialkowski
Bits related to the interface data width are only applicable to the
parallel interface and are irrelevant when the CSI controller is taking
input from the MIPI CSI-2 controller.

In prevision of adding support for this case, set these bits
conditionally so there is no ambiguity. The conditional block is
moved around before the interlaced conditional block for nicer code
symmetry (conditional blocks first) while at it.

Co-developed-by: Kévin L'hôpital 
Signed-off-by: Kévin L'hôpital 
Signed-off-by: Paul Kocialkowski 
---
 .../platform/sunxi/sun6i-csi/sun6i_csi.c  | 42 +++
 1 file changed, 25 insertions(+), 17 deletions(-)

diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
index 531a4cccd14a..f1150de94e98 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -378,8 +378,13 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev *sdev)
unsigned char bus_width;
u32 flags;
u32 cfg;
+   bool input_parallel = false;
bool input_interlaced = false;
 
+   if (endpoint->bus_type == V4L2_MBUS_PARALLEL ||
+   endpoint->bus_type == V4L2_MBUS_BT656)
+   input_parallel = true;
+
if (csi->config.field == V4L2_FIELD_INTERLACED
|| csi->config.field == V4L2_FIELD_INTERLACED_TB
|| csi->config.field == V4L2_FIELD_INTERLACED_BT)
@@ -395,6 +400,26 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev *sdev)
 CSI_IF_CFG_HREF_POL_MASK | CSI_IF_CFG_FIELD_MASK |
 CSI_IF_CFG_SRC_TYPE_MASK);
 
+   if (input_parallel) {
+   switch (bus_width) {
+   case 8:
+   cfg |= CSI_IF_CFG_IF_DATA_WIDTH_8BIT;
+   break;
+   case 10:
+   cfg |= CSI_IF_CFG_IF_DATA_WIDTH_10BIT;
+   break;
+   case 12:
+   cfg |= CSI_IF_CFG_IF_DATA_WIDTH_12BIT;
+   break;
+   case 16: /* No need to configure DATA_WIDTH for 16bit */
+   break;
+   default:
+   dev_warn(sdev->dev, "Unsupported bus width: %u\n",
+bus_width);
+   break;
+   }
+   }
+
if (input_interlaced)
cfg |= CSI_IF_CFG_SRC_TYPE_INTERLACED;
else
@@ -440,23 +465,6 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev *sdev)
break;
}
 
-   switch (bus_width) {
-   case 8:
-   cfg |= CSI_IF_CFG_IF_DATA_WIDTH_8BIT;
-   break;
-   case 10:
-   cfg |= CSI_IF_CFG_IF_DATA_WIDTH_10BIT;
-   break;
-   case 12:
-   cfg |= CSI_IF_CFG_IF_DATA_WIDTH_12BIT;
-   break;
-   case 16: /* No need to configure DATA_WIDTH for 16bit */
-   break;
-   default:
-   dev_warn(sdev->dev, "Unsupported bus width: %u\n", bus_width);
-   break;
-   }
-
regmap_write(sdev->regmap, CSI_IF_CFG_REG, cfg);
 }
 
-- 
2.29.2



[PATCH v4 06/15] dt-bindings: media: sun6i-a31-csi: Add MIPI CSI-2 input port

2020-12-31 Thread Paul Kocialkowski
The A31 CSI controller supports two distinct input interfaces:
parallel and an external MIPI CSI-2 bridge. The parallel interface
is often connected to a set of hardware pins while the MIPI CSI-2
bridge is an internal FIFO-ish link. As a result, these two inputs
are distinguished as two different ports.

Note that only one of the two may be present on a controller instance.
For example, the V3s has one controller dedicated to MIPI-CSI2 and one
dedicated to parallel.

Update the binding with an explicit ports node that holds two distinct
port nodes: one for parallel input and one for MIPI CSI-2.

This is backward-compatible with the single-port approach that was
previously taken for representing the parallel interface port, which
stays enumerated as fwnode port 0.

Note that additional ports may be added in the future, especially to
support feeding the CSI controller's output to the ISP.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Rob Herring 
---
 .../media/allwinner,sun6i-a31-csi.yaml| 88 ---
 1 file changed, 75 insertions(+), 13 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml 
b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
index 1fd9b5532a21..77ded77505e9 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
@@ -67,6 +67,62 @@ properties:
 
 additionalProperties: false
 
+  ports:
+type: object
+
+properties:
+  port@0:
+type: object
+description: Parallel input port, connect to a parallel sensor
+
+properties:
+  reg:
+const: 0
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+  bus-width:
+enum: [ 8, 10, 12, 16 ]
+
+  pclk-sample: true
+  hsync-active: true
+  vsync-active: true
+
+required:
+  - bus-width
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
+  port@1:
+type: object
+description: MIPI CSI-2 bridge input port
+
+properties:
+  reg:
+const: 1
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+required:
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
 required:
   - compatible
   - reg
@@ -95,19 +151,25 @@ examples:
   "ram";
 resets = < RST_BUS_CSI>;
 
-port {
-/* Parallel bus endpoint */
-csi1_ep: endpoint {
-remote-endpoint = <_ep>;
-bus-width = <16>;
-
-/*
- * If hsync-active/vsync-active are missing,
- * embedded BT.656 sync is used.
- */
- hsync-active = <0>; /* Active low */
- vsync-active = <0>; /* Active low */
- pclk-sample = <1>;  /* Rising */
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+/* Parallel bus endpoint */
+csi1_ep: endpoint {
+remote-endpoint = <_ep>;
+bus-width = <16>;
+
+/*
+ * If hsync-active/vsync-active are missing,
+ * embedded BT.656 sync is used.
+ */
+ hsync-active = <0>; /* Active low */
+ vsync-active = <0>; /* Active low */
+ pclk-sample = <1>;  /* Rising */
+};
 };
 };
 };
-- 
2.29.2



[PATCH v4 07/15] media: sun6i-csi: Add support for MIPI CSI-2 bridge input

2020-12-31 Thread Paul Kocialkowski
The A31 CSI controller supports a MIPI CSI-2 bridge input, which has
its own dedicated port in the fwnode graph.

Support for this input is added with this change:
- two pads are defined for the media entity instead of one
  and only one needs to be connected at a time;
- the pads currently match the fwnode graph representation;
- links are created between our pads and the subdevs for each
  interface and are no longer immutable so that userspace can select
  which interface to use in case both are bound to a subdev;
- fwnode endpoints are parsed and stored for each interface;
- the active subdev (and fwnode endpoint) is retrieved when validating
  the media link at stream on time and cleared at stream off;
- an error is raised if both links are active at the same time;
- the MIPI interface bit is set if the MIPI CSI-2 bridge endpoint is
  active.

In the future, the media entity representation might evolve to:
- distinguish the internal parallel bridge and data formatter;
- represent each of the 4 internal channels that can exist between
  the parallel bridge (for BT656 time-multiplex) and MIPI CSI-2
  (internal channels can be mapped to virtual channels);
- connect the controller's output to the ISP instead of its
  DMA engine.

Finally note that the MIPI CSI-2 bridges should not be linked in
the fwnode graph unless they have a sensor subdev attached.

Signed-off-by: Paul Kocialkowski 
---
 .../platform/sunxi/sun6i-csi/sun6i_csi.c  | 123 ++
 .../platform/sunxi/sun6i-csi/sun6i_csi.h  |   9 +-
 .../platform/sunxi/sun6i-csi/sun6i_video.c|  57 
 .../platform/sunxi/sun6i-csi/sun6i_video.h|   7 +-
 4 files changed, 142 insertions(+), 54 deletions(-)

diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
index f1150de94e98..dcf465d73579 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -49,6 +49,7 @@ static inline struct sun6i_csi_dev *sun6i_csi_to_dev(struct 
sun6i_csi *csi)
 
 /* TODO add 10&12 bit YUV, RGB support */
 bool sun6i_csi_is_format_supported(struct sun6i_csi *csi,
+  struct v4l2_fwnode_endpoint *endpoint,
   u32 pixformat, u32 mbus_code)
 {
struct sun6i_csi_dev *sdev = sun6i_csi_to_dev(csi);
@@ -58,9 +59,9 @@ bool sun6i_csi_is_format_supported(struct sun6i_csi *csi,
 * 8bit and 16bit bus width.
 * Identify the media bus format from device tree.
 */
-   if ((sdev->csi.v4l2_ep.bus_type == V4L2_MBUS_PARALLEL
-|| sdev->csi.v4l2_ep.bus_type == V4L2_MBUS_BT656)
-&& sdev->csi.v4l2_ep.bus.parallel.bus_width == 16) {
+   if ((endpoint->bus_type == V4L2_MBUS_PARALLEL ||
+endpoint->bus_type == V4L2_MBUS_BT656) &&
+   endpoint->bus.parallel.bus_width == 16) {
switch (pixformat) {
case V4L2_PIX_FMT_HM12:
case V4L2_PIX_FMT_NV12:
@@ -373,7 +374,7 @@ static enum csi_input_seq get_csi_input_seq(struct 
sun6i_csi_dev *sdev,
 
 static void sun6i_csi_setup_bus(struct sun6i_csi_dev *sdev)
 {
-   struct v4l2_fwnode_endpoint *endpoint = >csi.v4l2_ep;
+   struct v4l2_fwnode_endpoint *endpoint = sdev->csi.video.source_endpoint;
struct sun6i_csi *csi = >csi;
unsigned char bus_width;
u32 flags;
@@ -459,6 +460,9 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev *sdev)
if (flags & V4L2_MBUS_PCLK_SAMPLE_FALLING)
cfg |= CSI_IF_CFG_CLK_POL_FALLING_EDGE;
break;
+   case V4L2_MBUS_CSI2_DPHY:
+   cfg |= CSI_IF_CFG_MIPI_IF_MIPI;
+   break;
default:
dev_warn(sdev->dev, "Unsupported bus type: %d\n",
 endpoint->bus_type);
@@ -636,11 +640,11 @@ void sun6i_csi_set_stream(struct sun6i_csi *csi, bool 
enable)
  * Media Controller and V4L2
  */
 static int sun6i_csi_link_entity(struct sun6i_csi *csi,
+struct media_pad *sink_pad,
 struct media_entity *entity,
-struct fwnode_handle *fwnode)
+struct fwnode_handle *fwnode, bool enabled)
 {
struct media_entity *sink;
-   struct media_pad *sink_pad;
int src_pad_index;
int ret;
 
@@ -654,14 +658,12 @@ static int sun6i_csi_link_entity(struct sun6i_csi *csi,
src_pad_index = ret;
 
sink = >video.vdev.entity;
-   sink_pad = >video.pad;
 
dev_dbg(csi->dev, "creating %s:%u -> %s:%u link\n",
entity->name, src_pad_index, sink->name, sink_pad->index);
ret = media_create_pad_link(entity, src_pad_index, sink,
   

[PATCH v4 08/15] dt-bindings: media: Add A31 MIPI CSI-2 bindings documentation

2020-12-31 Thread Paul Kocialkowski
This introduces YAML bindings documentation for the A31 MIPI CSI-2
controller.

Signed-off-by: Paul Kocialkowski 
---
 .../media/allwinner,sun6i-a31-mipi-csi2.yaml  | 149 ++
 1 file changed, 149 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml

diff --git 
a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml 
b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
new file mode 100644
index ..bb05105c45b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
@@ -0,0 +1,149 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/allwinner,sun6i-a31-mipi-csi2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A31 MIPI CSI-2 Device Tree Bindings
+
+maintainers:
+  - Paul Kocialkowski 
+
+properties:
+  compatible:
+oneOf:
+  - const: allwinner,sun6i-a31-mipi-csi2
+  - items:
+  - const: allwinner,sun8i-v3s-mipi-csi2
+  - const: allwinner,sun6i-a31-mipi-csi2
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+items:
+  - description: Bus Clock
+  - description: Module Clock
+
+  clock-names:
+items:
+  - const: bus
+  - const: mod
+
+  phys:
+maxItems: 1
+description: MIPI D-PHY
+
+  resets:
+maxItems: 1
+
+  # See ./video-interfaces.txt for details
+  ports:
+type: object
+
+properties:
+  port@0:
+type: object
+description: Input port, connect to a MIPI CSI-2 sensor
+
+properties:
+  reg:
+const: 0
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+  data-lanes:
+minItems: 1
+maxItems: 4
+
+required:
+  - data-lanes
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
+  port@1:
+type: object
+description: Output port, connect to a CSI controller
+
+properties:
+  reg:
+const: 1
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+required:
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - resets
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+
+mipi_csi2: csi@1cb1000 {
+compatible = "allwinner,sun8i-v3s-mipi-csi2",
+ "allwinner,sun6i-a31-mipi-csi2";
+reg = <0x01cb1000 0x1000>;
+interrupts = ;
+clocks = < CLK_BUS_CSI>,
+ < CLK_CSI1_SCLK>;
+clock-names = "bus", "mod";
+resets = < RST_BUS_CSI>;
+
+phys = <>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+mipi_csi2_in: port@0 {
+reg = <0>;
+
+mipi_csi2_in_ov5648: endpoint {
+data-lanes = <1 2 3 4>;
+
+remote-endpoint = <_out_mipi_csi2>;
+};
+};
+
+mipi_csi2_out: port@1 {
+reg = <1>;
+
+mipi_csi2_out_csi0: endpoint {
+remote-endpoint = <_in_mipi_csi2>;
+};
+};
+};
+};
+
+...
-- 
2.29.2



[PATCH v4 09/15] media: sunxi: Add support for the A31 MIPI CSI-2 controller

2020-12-31 Thread Paul Kocialkowski
The A31 MIPI CSI-2 controller is a dedicated MIPI CSI-2 bridge
found on Allwinner SoCs such as the A31 and V3/V3s.

It is a standalone block, connected to the CSI controller on one side
and to the MIPI D-PHY block on the other. It has a dedicated address
space, interrupt line and clock.

It is represented as a V4L2 subdev to the CSI controller and takes a
MIPI CSI-2 sensor as its own subdev, all using the fwnode graph and
media controller API.

Only 8-bit and 10-bit Bayer formats are currently supported.
While up to 4 internal channels to the CSI controller exist, only one
is currently supported by this implementation.

Signed-off-by: Paul Kocialkowski 
---
 drivers/media/platform/sunxi/Kconfig  |   1 +
 drivers/media/platform/sunxi/Makefile |   1 +
 .../platform/sunxi/sun6i-mipi-csi2/Kconfig|  12 +
 .../platform/sunxi/sun6i-mipi-csi2/Makefile   |   4 +
 .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c   | 590 ++
 .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h   | 117 
 6 files changed, 725 insertions(+)
 create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
 create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
 create mode 100644 
drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
 create mode 100644 
drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h

diff --git a/drivers/media/platform/sunxi/Kconfig 
b/drivers/media/platform/sunxi/Kconfig
index 7151cc249afa..9684e07454ad 100644
--- a/drivers/media/platform/sunxi/Kconfig
+++ b/drivers/media/platform/sunxi/Kconfig
@@ -2,3 +2,4 @@
 
 source "drivers/media/platform/sunxi/sun4i-csi/Kconfig"
 source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
+source "drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig"
diff --git a/drivers/media/platform/sunxi/Makefile 
b/drivers/media/platform/sunxi/Makefile
index fc537c9f5ca9..887a7cae8fca 100644
--- a/drivers/media/platform/sunxi/Makefile
+++ b/drivers/media/platform/sunxi/Makefile
@@ -2,5 +2,6 @@
 
 obj-y  += sun4i-csi/
 obj-y  += sun6i-csi/
+obj-y  += sun6i-mipi-csi2/
 obj-y  += sun8i-di/
 obj-y  += sun8i-rotate/
diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig 
b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
new file mode 100644
index ..47f1bb0779a8
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config VIDEO_SUN6I_MIPI_CSI2
+   tristate "Allwinner A31 MIPI CSI-2 Controller Driver"
+   depends on ARCH_SUNXI || COMPILE_TEST
+   depends on PM && COMMON_CLK && VIDEO_V4L2
+   select REGMAP_MMIO
+   select PHY_SUN6I_MIPI_DPHY
+   select MEDIA_CONTROLLER
+   select VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+   help
+  Support for the Allwinner A31 MIPI CSI-2 Controller.
diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile 
b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
new file mode 100644
index ..14e4e03818b5
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-only
+sun6i-mipi-csi2-y += sun6i_mipi_csi2.o
+
+obj-$(CONFIG_VIDEO_SUN6I_MIPI_CSI2) += sun6i-mipi-csi2.o
diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c 
b/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
new file mode 100644
index ..87307beda4cf
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
@@ -0,0 +1,590 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 Bootlin
+ * Author: Paul Kocialkowski 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sun6i_mipi_csi2.h"
+
+#define MODULE_NAME"sun6i-mipi-csi2"
+
+static const u32 sun6i_mipi_csi2_mbus_codes[] = {
+   MEDIA_BUS_FMT_SBGGR8_1X8,
+   MEDIA_BUS_FMT_SGBRG8_1X8,
+   MEDIA_BUS_FMT_SGRBG8_1X8,
+   MEDIA_BUS_FMT_SRGGB8_1X8,
+   MEDIA_BUS_FMT_SBGGR10_1X10,
+   MEDIA_BUS_FMT_SGBRG10_1X10,
+   MEDIA_BUS_FMT_SGRBG10_1X10,
+   MEDIA_BUS_FMT_SRGGB10_1X10,
+};
+
+/* Video */
+
+static int sun6i_mipi_csi2_s_stream(struct v4l2_subdev *subdev, int on)
+{
+   struct sun6i_mipi_csi2_video *video =
+   sun6i_mipi_csi2_subdev_video(subdev);
+   struct sun6i_mipi_csi2_dev *cdev = sun6i_mipi_csi2_video_dev(video);
+   struct v4l2_subdev *remote_subdev = video->remote_subdev;
+   struct v4l2_fwnode_bus_mipi_csi2 *bus_mipi_csi2 =
+   >endpoint.bus.mipi_csi2;
+   union phy_configure_opts dphy_opts = { 0 };
+   struct phy_configure_opts_mipi_dphy *dphy_cfg = _opts.mipi_dphy;
+   struct regmap *regmap = cdev->regmap;
+   struct v4l2_ctrl *ct

[PATCH v4 03/15] phy: allwinner: phy-sun6i-mipi-dphy: Support D-PHY Rx mode for MIPI CSI-2

2020-12-31 Thread Paul Kocialkowski
The Allwinner A31 D-PHY supports both Rx and Tx modes. While the latter
is already supported and used for MIPI DSI this adds support for the
former, to be used with MIPI CSI-2.

This implementation is inspired by Allwinner's V3s Linux SDK
implementation, which was used as a documentation base.

Signed-off-by: Paul Kocialkowski 
Acked-by: Maxime Ripard 
---
 drivers/phy/allwinner/phy-sun6i-mipi-dphy.c | 164 +++-
 1 file changed, 160 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c 
b/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
index 1fa761ba6cbb..0389b6b670d6 100644
--- a/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
+++ b/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
@@ -24,6 +24,14 @@
 #define SUN6I_DPHY_TX_CTL_REG  0x04
 #define SUN6I_DPHY_TX_CTL_HS_TX_CLK_CONT   BIT(28)
 
+#define SUN6I_DPHY_RX_CTL_REG  0x08
+#define SUN6I_DPHY_RX_CTL_EN_DBC   BIT(31)
+#define SUN6I_DPHY_RX_CTL_RX_CLK_FORCE BIT(24)
+#define SUN6I_DPHY_RX_CTL_RX_D3_FORCE  BIT(23)
+#define SUN6I_DPHY_RX_CTL_RX_D2_FORCE  BIT(22)
+#define SUN6I_DPHY_RX_CTL_RX_D1_FORCE  BIT(21)
+#define SUN6I_DPHY_RX_CTL_RX_D0_FORCE  BIT(20)
+
 #define SUN6I_DPHY_TX_TIME0_REG0x10
 #define SUN6I_DPHY_TX_TIME0_HS_TRAIL(n)(((n) & 0xff) << 24)
 #define SUN6I_DPHY_TX_TIME0_HS_PREPARE(n)  (((n) & 0xff) << 16)
@@ -44,12 +52,29 @@
 #define SUN6I_DPHY_TX_TIME4_HS_TX_ANA1(n)  (((n) & 0xff) << 8)
 #define SUN6I_DPHY_TX_TIME4_HS_TX_ANA0(n)  ((n) & 0xff)
 
+#define SUN6I_DPHY_RX_TIME0_REG0x30
+#define SUN6I_DPHY_RX_TIME0_HS_RX_SYNC(n)  (((n) & 0xff) << 24)
+#define SUN6I_DPHY_RX_TIME0_HS_RX_CLK_MISS(n)  (((n) & 0xff) << 16)
+#define SUN6I_DPHY_RX_TIME0_LP_RX(n)   (((n) & 0xff) << 8)
+
+#define SUN6I_DPHY_RX_TIME1_REG0x34
+#define SUN6I_DPHY_RX_TIME1_RX_DLY(n)  (((n) & 0xfff) << 20)
+#define SUN6I_DPHY_RX_TIME1_LP_RX_ULPS_WP(n)   ((n) & 0xf)
+
+#define SUN6I_DPHY_RX_TIME2_REG0x38
+#define SUN6I_DPHY_RX_TIME2_HS_RX_ANA1(n)  (((n) & 0xff) << 8)
+#define SUN6I_DPHY_RX_TIME2_HS_RX_ANA0(n)  ((n) & 0xff)
+
+#define SUN6I_DPHY_RX_TIME3_REG0x40
+#define SUN6I_DPHY_RX_TIME3_LPRST_DLY(n)   (((n) & 0x) << 16)
+
 #define SUN6I_DPHY_ANA0_REG0x4c
 #define SUN6I_DPHY_ANA0_REG_PWSBIT(31)
 #define SUN6I_DPHY_ANA0_REG_DMPC   BIT(28)
 #define SUN6I_DPHY_ANA0_REG_DMPD(n)(((n) & 0xf) << 24)
 #define SUN6I_DPHY_ANA0_REG_SLV(n) (((n) & 7) << 12)
 #define SUN6I_DPHY_ANA0_REG_DEN(n) (((n) & 0xf) << 8)
+#define SUN6I_DPHY_ANA0_REG_SFB(n) (((n) & 3) << 2)
 
 #define SUN6I_DPHY_ANA1_REG0x50
 #define SUN6I_DPHY_ANA1_REG_VTTMODEBIT(31)
@@ -92,6 +117,8 @@ struct sun6i_dphy {
 
struct phy  *phy;
struct phy_configure_opts_mipi_dphy config;
+
+   int submode;
 };
 
 static int sun6i_dphy_init(struct phy *phy)
@@ -105,6 +132,18 @@ static int sun6i_dphy_init(struct phy *phy)
return 0;
 }
 
+static int sun6i_dphy_set_mode(struct phy *phy, enum phy_mode mode, int 
submode)
+{
+   struct sun6i_dphy *dphy = phy_get_drvdata(phy);
+
+   if (mode != PHY_MODE_MIPI_DPHY)
+   return -EINVAL;
+
+   dphy->submode = submode;
+
+   return 0;
+}
+
 static int sun6i_dphy_configure(struct phy *phy, union phy_configure_opts 
*opts)
 {
struct sun6i_dphy *dphy = phy_get_drvdata(phy);
@@ -119,9 +158,8 @@ static int sun6i_dphy_configure(struct phy *phy, union 
phy_configure_opts *opts)
return 0;
 }
 
-static int sun6i_dphy_power_on(struct phy *phy)
+static int sun6i_dphy_tx_power_on(struct sun6i_dphy *dphy)
 {
-   struct sun6i_dphy *dphy = phy_get_drvdata(phy);
u8 lanes_mask = GENMASK(dphy->config.lanes - 1, 0);
 
regmap_write(dphy->regs, SUN6I_DPHY_TX_CTL_REG,
@@ -211,12 +249,129 @@ static int sun6i_dphy_power_on(struct phy *phy)
return 0;
 }
 
+static int sun6i_dphy_rx_power_on(struct sun6i_dphy *dphy)
+{
+   /* Physical clock rate is actually half of symbol rate with DDR. */
+   unsigned long mipi_symbol_rate = dphy->config.hs_clk_rate;
+   unsigned long dphy_clk_rate;
+   unsigned int rx_dly;
+   unsigned int lprst_dly;
+   u32 value;
+
+   dphy_clk_rate = clk_get_rate(dphy->mod_clk);
+   if (!dphy_clk_rate)
+   return -EINVAL;
+
+   /* Hardcoded timing parameters from the Allwinner BSP. */
+   regmap_write(dphy->regs, SUN6I_DPHY_RX_TIME0_REG,
+SUN6I_DPHY_RX_TIME0_HS_RX_SYNC(255) |
+SUN6I_DPHY_RX_TIME0_HS_RX_CLK_MISS(255) |
+SUN6I

[PATCH v4 15/15] MAINTAINERS: Add entry for the Allwinner A83T MIPI CSI-2 bridge

2020-12-31 Thread Paul Kocialkowski
Add myself as maintainer of the A83T MIPI CSI-2 bridge media driver.

Signed-off-by: Paul Kocialkowski 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index a1352171778b..3b48612657b6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -717,6 +717,14 @@ T: git git://linuxtv.org/media_tree.git
 F: 
Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
 F: drivers/media/platform/sunxi/sun6i-mipi-csi2/
 
+ALLWINNER A83T MIPI CSI-2 BRIDGE
+M: Paul Kocialkowski 
+L: linux-me...@vger.kernel.org
+S: Maintained
+T: git git://linuxtv.org/media_tree.git
+F: 
Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml
+F: drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/
+
 ALLWINNER CPUFREQ DRIVER
 M: Yangtao Li 
 L: linux...@vger.kernel.org
-- 
2.29.2



[PATCH v4 14/15] ARM: dts: sun8i: a83t: Add MIPI CSI-2 controller node

2020-12-31 Thread Paul Kocialkowski
MIPI CSI-2 is supported on the A83T with a dedicated controller that
covers both the protocol and D-PHY. It can be connected to the CSI
interface as a V4L2 subdev through the fwnode graph.

This is not done by default since connecting the bridge without a
subdev attached to it will cause a failure on the CSI driver.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index c010b27fdb6a..d6d55c12b995 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -1066,6 +1066,32 @@ csi_in: port {
};
};
 
+   mipi_csi2: csi@1cb1000 {
+   compatible = "allwinner,sun8i-a83t-mipi-csi2";
+   reg = <0x01cb1000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_CSI>,
+< CLK_CSI_SCLK>,
+< CLK_MIPI_CSI>,
+< CLK_CSI_MISC>;
+   clock-names = "bus", "mod", "mipi", "misc";
+   resets = < RST_BUS_CSI>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mipi_csi2_in: port@0 {
+   reg = <0>;
+   };
+
+   mipi_csi2_out: port@1 {
+   reg = <1>;
+   };
+   };
+   };
+
hdmi: hdmi@1ee {
compatible = "allwinner,sun8i-a83t-dw-hdmi";
reg = <0x01ee 0x1>;
-- 
2.29.2



[PATCH v4 04/15] media: sun6i-csi: Use common V4L2 format info for storage bpp

2020-12-31 Thread Paul Kocialkowski
V4L2 has a common helper which can be used for calculating the number
of stored bits per pixels of a given (stored) image format.

Use the helper-returned structure instead of our own switch/case list.
Note that a few formats are not in that list so we keep them as
special cases.

The custom switch/case was also wrong concerning 10/12-bit Bayer
formats, which are aligned to 16 bits in memory. Using the common
helper fixes it.

Fixes: 5cc7522d8965 ("media: sun6i: Add support for Allwinner CSI V3s")
Signed-off-by: Paul Kocialkowski 
Acked-by: Maxime Ripard 
---
 .../platform/sunxi/sun6i-csi/sun6i_csi.h  | 55 +++
 1 file changed, 20 insertions(+), 35 deletions(-)

diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
index c626821aaedb..092445f04c60 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
@@ -86,53 +86,38 @@ void sun6i_csi_update_buf_addr(struct sun6i_csi *csi, 
dma_addr_t addr);
  */
 void sun6i_csi_set_stream(struct sun6i_csi *csi, bool enable);
 
-/* get bpp form v4l2 pixformat */
+/* get memory storage bpp from v4l2 pixformat */
 static inline int sun6i_csi_get_bpp(unsigned int pixformat)
 {
+   const struct v4l2_format_info *info;
+   unsigned int i;
+   int bpp = 0;
+
+   /* Handle special cases unknown to V4L2 format info first. */
switch (pixformat) {
-   case V4L2_PIX_FMT_SBGGR8:
-   case V4L2_PIX_FMT_SGBRG8:
-   case V4L2_PIX_FMT_SGRBG8:
-   case V4L2_PIX_FMT_SRGGB8:
case V4L2_PIX_FMT_JPEG:
return 8;
-   case V4L2_PIX_FMT_SBGGR10:
-   case V4L2_PIX_FMT_SGBRG10:
-   case V4L2_PIX_FMT_SGRBG10:
-   case V4L2_PIX_FMT_SRGGB10:
-   return 10;
-   case V4L2_PIX_FMT_SBGGR12:
-   case V4L2_PIX_FMT_SGBRG12:
-   case V4L2_PIX_FMT_SGRBG12:
-   case V4L2_PIX_FMT_SRGGB12:
case V4L2_PIX_FMT_HM12:
-   case V4L2_PIX_FMT_NV12:
-   case V4L2_PIX_FMT_NV21:
-   case V4L2_PIX_FMT_YUV420:
-   case V4L2_PIX_FMT_YVU420:
return 12;
-   case V4L2_PIX_FMT_YUYV:
-   case V4L2_PIX_FMT_YVYU:
-   case V4L2_PIX_FMT_UYVY:
-   case V4L2_PIX_FMT_VYUY:
-   case V4L2_PIX_FMT_NV16:
-   case V4L2_PIX_FMT_NV61:
-   case V4L2_PIX_FMT_YUV422P:
-   case V4L2_PIX_FMT_RGB565:
case V4L2_PIX_FMT_RGB565X:
return 16;
-   case V4L2_PIX_FMT_RGB24:
-   case V4L2_PIX_FMT_BGR24:
-   return 24;
-   case V4L2_PIX_FMT_RGB32:
-   case V4L2_PIX_FMT_BGR32:
-   return 32;
-   default:
+   }
+
+   info = v4l2_format_info(pixformat);
+   if (!info) {
WARN(1, "Unsupported pixformat: 0x%x\n", pixformat);
-   break;
+   return 0;
+   }
+
+   for (i = 0; i < info->comp_planes; i++) {
+   unsigned int hdiv = (i == 0) ? 1 : info->hdiv;
+   unsigned int vdiv = (i == 0) ? 1 : info->vdiv;
+
+   /* We return bits per pixel while V4L2 format info is bytes. */
+   bpp += 8 * info->bpp[i] / hdiv / vdiv;
}
 
-   return 0;
+   return bpp;
 }
 
 #endif /* __SUN6I_CSI_H__ */
-- 
2.29.2



[PATCH v4 13/15] media: sunxi: Add support for the A83T MIPI CSI-2 controller

2020-12-31 Thread Paul Kocialkowski
The A83T supports MIPI CSI-2 with a composite controller, covering
both the protocol logic and the D-PHY implementation. This controller
seems to be found on the A83T only and probably was abandoned since.

This implementation splits the protocol and D-PHY registers and
uses the PHY framework internally. The D-PHY is not registered as a
standalone PHY driver since it cannot be used with any other
controller.

There are a few notable points about the controller:
- The initialisation sequence involes writing specific magic init
  values that do not seem to make any particular sense given the
  concerned register fields;
- Interrupts appear to be hitting regardless of the interrupt mask
  registers, which can cause a serious flood when transmission errors
  occur.

Only 8-bit and 10-bit Bayer formats are currently supported.
While up to 4 internal channels to the CSI controller exist, only one
is currently supported by this implementation.

This work is based on the first version of the driver submitted by
Kévin L'hôpital, which was adapted to mainline from the Allwinner BSP.
This version integrates MIPI CSI-2 support as a standalone V4L2 subdev
instead of merging it in the sun6i-csi driver.

It was tested on a Banana Pi M3 board with an OV8865 sensor in a 4-lane
configuration.

Signed-off-by: Paul Kocialkowski 
---
 drivers/media/platform/sunxi/Kconfig  |   1 +
 drivers/media/platform/sunxi/Makefile |   1 +
 .../sunxi/sun8i-a83t-mipi-csi2/Kconfig|  11 +
 .../sunxi/sun8i-a83t-mipi-csi2/Makefile   |   4 +
 .../sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.c|  92 +++
 .../sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.h|  39 ++
 .../sun8i_a83t_mipi_csi2.c| 657 ++
 .../sun8i_a83t_mipi_csi2.h| 197 ++
 8 files changed, 1002 insertions(+)
 create mode 100644 drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Kconfig
 create mode 100644 drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Makefile
 create mode 100644 
drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.c
 create mode 100644 
drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.h
 create mode 100644 
drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_mipi_csi2.c
 create mode 100644 
drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_mipi_csi2.h

diff --git a/drivers/media/platform/sunxi/Kconfig 
b/drivers/media/platform/sunxi/Kconfig
index 9684e07454ad..db4c07be7e4c 100644
--- a/drivers/media/platform/sunxi/Kconfig
+++ b/drivers/media/platform/sunxi/Kconfig
@@ -3,3 +3,4 @@
 source "drivers/media/platform/sunxi/sun4i-csi/Kconfig"
 source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
 source "drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig"
+source "drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Kconfig"
diff --git a/drivers/media/platform/sunxi/Makefile 
b/drivers/media/platform/sunxi/Makefile
index 887a7cae8fca..9aa01cb01883 100644
--- a/drivers/media/platform/sunxi/Makefile
+++ b/drivers/media/platform/sunxi/Makefile
@@ -3,5 +3,6 @@
 obj-y  += sun4i-csi/
 obj-y  += sun6i-csi/
 obj-y  += sun6i-mipi-csi2/
+obj-y  += sun8i-a83t-mipi-csi2/
 obj-y  += sun8i-di/
 obj-y  += sun8i-rotate/
diff --git a/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Kconfig 
b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Kconfig
new file mode 100644
index ..60e7a9c41065
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Kconfig
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config VIDEO_SUN8I_A83T_MIPI_CSI2
+   tristate "Allwinner A83T MIPI CSI-2 Controller and D-PHY Driver"
+   depends on ARCH_SUNXI || COMPILE_TEST
+   depends on PM && COMMON_CLK && VIDEO_V4L2
+   select REGMAP_MMIO
+   select MEDIA_CONTROLLER
+   select VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+   help
+  Support for the Allwinner A83T MIPI CSI-2 Controller and D-PHY.
diff --git a/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Makefile 
b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Makefile
new file mode 100644
index ..1427d15a879a
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-only
+sun8i-a83t-mipi-csi2-y += sun8i_a83t_mipi_csi2.o sun8i_a83t_dphy.o
+
+obj-$(CONFIG_VIDEO_SUN8I_A83T_MIPI_CSI2) += sun8i-a83t-mipi-csi2.o
diff --git 
a/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.c 
b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.c
new file mode 100644
index ..c380065eb7c9
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.c
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 Bootlin
+ * Author: Paul Kocialkowski 
+ */
+
+#include 
+#include 
+
+#include &q

[PATCH v4 01/15] docs: phy: Add a part about PHY mode and submode

2020-12-31 Thread Paul Kocialkowski
Besides giving pointers to the relevant functions for PHY mode and
submode configuration, this clarifies the need to set them before
powering on the PHY.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Maxime Ripard 
---
 Documentation/driver-api/phy/phy.rst | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/driver-api/phy/phy.rst 
b/Documentation/driver-api/phy/phy.rst
index 8fc1ce0bb905..6cbc72707a49 100644
--- a/Documentation/driver-api/phy/phy.rst
+++ b/Documentation/driver-api/phy/phy.rst
@@ -195,3 +195,21 @@ DeviceTree Binding
 
 The documentation for PHY dt binding can be found @
 Documentation/devicetree/bindings/phy/phy-bindings.txt
+
+PHY Mode and Submode
+
+
+Once a reference to a PHY is obtained by a controller, the PHY can be 
configured
+to a PHY mode and submode. PHY modes are described in the `phy_mode` enum while
+submodes are specific to the selected PHY mode.
+
+Mode and submode configuration is done by calling::
+
+   int phy_set_mode_ext(struct phy *phy, enum phy_mode mode, int submode);
+
+If no submode is to be configured, users can call::
+
+   int phy_set_mode(struct phy *phy, enum phy_mode mode);
+
+The PHY mode and submode must not be configured after the PHY has already been
+powered on.
-- 
2.29.2



[PATCH v4 02/15] phy: Distinguish between Rx and Tx for MIPI D-PHY with submodes

2020-12-31 Thread Paul Kocialkowski
As some D-PHY controllers support both Rx and Tx mode, we need a way for
users to explicitly request one or the other. For instance, Rx mode can
be used along with MIPI CSI-2 while Tx mode can be used with MIPI DSI.

Introduce new MIPI D-PHY PHY submodes to use with PHY_MODE_MIPI_DPHY.
The default (zero value) is kept to Tx so only the rkisp1 driver, which
uses D-PHY in Rx mode, needs to be adapted.

Signed-off-by: Paul Kocialkowski 
Acked-by: Helen Koike 
---
 drivers/staging/media/rkisp1/rkisp1-isp.c |  3 ++-
 include/linux/phy/phy-mipi-dphy.h | 13 +
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/rkisp1/rkisp1-isp.c 
b/drivers/staging/media/rkisp1/rkisp1-isp.c
index a9715b0b7264..f1167995688a 100644
--- a/drivers/staging/media/rkisp1/rkisp1-isp.c
+++ b/drivers/staging/media/rkisp1/rkisp1-isp.c
@@ -914,7 +914,8 @@ static int rkisp1_mipi_csi2_start(struct rkisp1_isp *isp,
 
phy_mipi_dphy_get_default_config(pixel_clock, isp->sink_fmt->bus_width,
 sensor->lanes, cfg);
-   phy_set_mode(sensor->dphy, PHY_MODE_MIPI_DPHY);
+   phy_set_mode_ext(cdev->dphy, PHY_MODE_MIPI_DPHY,
+PHY_MIPI_DPHY_SUBMODE_RX);
phy_configure(sensor->dphy, );
phy_power_on(sensor->dphy);
 
diff --git a/include/linux/phy/phy-mipi-dphy.h 
b/include/linux/phy/phy-mipi-dphy.h
index a877ffee845d..0f57ef46a8b5 100644
--- a/include/linux/phy/phy-mipi-dphy.h
+++ b/include/linux/phy/phy-mipi-dphy.h
@@ -6,6 +6,19 @@
 #ifndef __PHY_MIPI_DPHY_H_
 #define __PHY_MIPI_DPHY_H_
 
+/**
+ * enum phy_mipi_dphy_submode - MIPI D-PHY sub-mode
+ *
+ * A MIPI D-PHY can be used to transmit or receive data.
+ * Since some controllers can support both, the direction to enable is 
specified
+ * with the PHY sub-mode. Transmit is assumed by default with phy_set_mode.
+ */
+
+enum phy_mipi_dphy_submode {
+   PHY_MIPI_DPHY_SUBMODE_TX = 0,
+   PHY_MIPI_DPHY_SUBMODE_RX,
+};
+
 /**
  * struct phy_configure_opts_mipi_dphy - MIPI D-PHY configuration set
  *
-- 
2.29.2



[PATCH v4 11/15] MAINTAINERS: Add entry for the Allwinner A31 MIPI CSI-2 bridge

2020-12-31 Thread Paul Kocialkowski
Add myself as maintainer of the A31 MIPI CSI-2 bridge media driver.

Signed-off-by: Paul Kocialkowski 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0644128640fb..a1352171778b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -709,6 +709,14 @@ T: git git://linuxtv.org/media_tree.git
 F: Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml
 F: drivers/media/platform/sunxi/sun4i-csi/
 
+ALLWINNER A31 MIPI CSI-2 BRIDGE
+M: Paul Kocialkowski 
+L: linux-me...@vger.kernel.org
+S: Maintained
+T: git git://linuxtv.org/media_tree.git
+F: 
Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
+F: drivers/media/platform/sunxi/sun6i-mipi-csi2/
+
 ALLWINNER CPUFREQ DRIVER
 M: Yangtao Li 
 L: linux...@vger.kernel.org
-- 
2.29.2



[PATCH v4 00/15] Allwinner MIPI CSI-2 support for A31/V3s/A83T

2020-12-31 Thread Paul Kocialkowski
   test VIDIOC_EXPBUF: FAIL
test Requests: OK (Not Supported)

Total for sun6i-video device /dev/video0: 45, Succeeded: 44, Failed: 1, 
Warnings: 1

# sun6i-csi + sun8i-a83t-mipi-csi2 + ov8865

v4l2-compliance SHA: not available, 32 bits

Compliance test for sun6i-video device /dev/video0:

Driver Info:
Driver name  : sun6i-video
Card type: sun6i-csi
Bus info : platform:camera
Driver version   : 5.10.0
Capabilities : 0x8421
Video Capture
Streaming
Extended Pix Format
Device Capabilities
Device Caps  : 0x0421
Video Capture
Streaming
Extended Pix Format
Media Driver Info:
Driver name  : sun6i-csi
Model: Allwinner Video Capture Device
Serial   : 
Bus info : platform:1cb.camera
Media version: 5.10.0
Hardware revision: 0x (0)
Driver version   : 5.10.0
Interface Info:
ID   : 0x0304
Type : V4L Video
Entity Info:
ID   : 0x0001 (1)
Name : sun6i-csi
Function : V4L2 I/O
Pad 0x0102   : 0: Sink
Pad 0x0103   : 1: Sink
  Link 0x020d: from remote pad 0x108 of entity 
'sun8i-a83t-mipi-csi2': Data, Enabled

Required ioctls:
test MC information (see 'Media Driver Info' above): OK
warn: v4l2-compliance.cpp(633): media bus_info 
'platform:1cb.camera' differs from V4L2 bus_info 'platform:camera'
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second /dev/video0 open: OK
warn: v4l2-compliance.cpp(633): media bus_info 
'platform:1cb.camera' differs from V4L2 bus_info 'platform:camera'
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls (Input 0):
warn: v4l2-test-controls.cpp(92): Exposure: (max - min) % step 
!= 0
warn: v4l2-test-controls.cpp(92): Gain: (max - min) % step != 0
warn: v4l2-test-controls.cpp(92): Exposure: (max - min) % step 
!= 0
warn: v4l2-test-controls.cpp(92): Gain: (max - min) % step != 0
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 11 Private Controls: 0

Format ioctls (Input 0):
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK

Codec ioctls (Input 0):
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls (Input 0):
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK
test Requests: OK (Not Supported)

Total for sun6i-video device /dev/video0: 45, Succeeded: 45, Failed: 0, 
Warnings: 6

Paul Kocialkowski (15):
  docs: phy: Add a part about PHY mode and submode
  phy: Distinguish between Rx and Tx for MIPI D-PHY with submodes
  phy: allwinner: phy-sun6i-mipi-dphy: Support D-PHY Rx mode for MIPI
CSI-2
  media: sun6i-csi: Use common V4L2 format info for storage bpp
  media: sun6i-csi: Only configure the interface data width for parallel
  dt-binding

[PATCH NOT FOR MERGE v4 3/3] ARM: dts: sun8i: a83t: bananapi-m3: Enable MIPI CSI-2 with OV8865

2020-12-31 Thread Paul Kocialkowski
From: Kévin L'hôpital 

The Bananapi M3 supports a camera module which includes an OV8865 sensor
connected via the parallel CSI interface and an OV8865 sensor connected
via MIPI CSI-2.

The I2C2 bus is shared by the two sensors as well as the (active-low)
reset signal, but each sensor has it own shutdown line.

Signed-off-by: Kévin L'hôpital 
Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 102 +++
 1 file changed, 102 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts 
b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index 431f70234d36..bebe843a069b 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -85,6 +85,30 @@ green {
};
};
 
+   reg_ov8865_avdd: ov8865-avdd {
+   compatible = "regulator-fixed";
+   regulator-name = "ov8865-avdd";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   vin-supply = <_dldo4>;
+   };
+
+   reg_ov8865_dovdd: ov8865-dovdd {
+   compatible = "regulator-fixed";
+   regulator-name = "ov8865-dovdd";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   vin-supply = <_dldo4>;
+   };
+
+   reg_ov8865_dvdd: ov8865-dvdd {
+   compatible = "regulator-fixed";
+   regulator-name = "ov8865-dvdd";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   vin-supply = <_eldo1>;
+   };
+
reg_usb1_vbus: reg-usb1-vbus {
compatible = "regulator-fixed";
regulator-name = "usb1-vbus";
@@ -115,6 +139,23 @@  {
cpu-supply = <_dcdc3>;
 };
 
+ {
+   status = "okay";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+
+   csi_in_mipi_csi2: endpoint {
+   remote-endpoint = <_csi2_out_csi>;
+   };
+   };
+   };
+};
+
  {
status = "okay";
 };
@@ -147,6 +188,36 @@ hdmi_out_con: endpoint {
};
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pe_pins>;
+   status = "okay";
+
+   ov8865: camera@36 {
+   compatible = "ovti,ov8865";
+   reg = <0x36>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_mclk_pin>;
+   clocks = < CLK_CSI_MCLK>;
+   assigned-clocks = < CLK_CSI_MCLK>;
+   assigned-clock-rates = <2400>;
+   avdd-supply = <_ov8865_avdd>;
+   dovdd-supply = <_ov8865_dovdd>;
+   dvdd-supply = <_ov8865_dvdd>;
+   powerdown-gpios = < 4 17 GPIO_ACTIVE_LOW>; /* PE17 */
+   reset-gpios = < 4 16 GPIO_ACTIVE_LOW>; /* PE16 */
+
+   port {
+   ov8865_out_mipi_csi2: endpoint {
+   data-lanes = <1 2 3 4>;
+   link-frequencies = /bits/ 64 <36000>;
+
+   remote-endpoint = <_csi2_in_ov8865>;
+   };
+   };
+   };
+};
+
  {
rgmii_phy: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
@@ -154,6 +225,24 @@ rgmii_phy: ethernet-phy@1 {
};
 };
 
+_csi2 {
+   status = "okay";
+};
+
+_csi2_in {
+   mipi_csi2_in_ov8865: endpoint {
+   data-lanes = <1 2 3 4>;
+
+   remote-endpoint = <_out_mipi_csi2>;
+   };
+};
+
+_csi2_out {
+   mipi_csi2_out_csi: endpoint {
+   remote-endpoint = <_in_mipi_csi2>;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
@@ -327,11 +416,24 @@ _dldo3 {
regulator-name = "vcc-pd";
 };
 
+_dldo4 {
+   regulator-always-on;
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-name = "avdd-csi";
+};
+
 _drivevbus {
regulator-name = "usb0-vbus";
status = "okay";
 };
 
+_eldo1 {
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   regulator-name = "dvdd-csi-r";
+};
+
 _fldo1 {
regulator-min-microvolt = <108>;
regulator-max-microvolt = <132>;
-- 
2.29.2



[PATCH v4 2/3] media: i2c: Add support for the OV8865 image sensor

2020-12-31 Thread Paul Kocialkowski
The OV8865 is a 8 Mpx CMOS image sensor producing 3264x2448 at 30 fps.
Other modes (including some with sub-sampling) are available too.
It outputs 10-bit bayer CFA data through a MIPI CSI-2 interface with
up to 4 lanes supported.

Some register initialisation sequences are still needed for this driver,
as they cover registers for which no documentation is available.

This work is based on the first version of the driver submitted by
Kévin L'hôpital, which was adapted to mainline from the Allwinner BSP.
This version is a rewrite of the first version that matches the structure
of the OV5648 driver, with explicit PLL configuration, all the necessary
mode-specific fields, associatied registers and reduced static sequences.

It was tested with the Banana Pi Camera Board v3 and the Banana Pi M3.

Co-developed-by: Kévin L'hôpital 
Signed-off-by: Kévin L'hôpital 
Signed-off-by: Paul Kocialkowski 
---
 drivers/media/i2c/Kconfig  |   13 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov8865.c | 2972 
 3 files changed, 2986 insertions(+)
 create mode 100644 drivers/media/i2c/ov8865.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index c0470a8b9a80..6bc505c1f171 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -1046,6 +1046,19 @@ config VIDEO_OV8856
  To compile this driver as a module, choose M here: the
  module will be called ov8856.
 
+config VIDEO_OV8865
+   tristate "OmniVision OV8865 sensor support"
+   depends on I2C && PM && VIDEO_V4L2
+   select MEDIA_CONTROLLER
+   select VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+   help
+ This is a Video4Linux2 sensor driver for OmniVision
+ OV8865 camera sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov8865.
+
 config VIDEO_OV9640
tristate "OmniVision OV9640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 15d4d6382582..505c2067e780 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_OV772X) += ov772x.o
 obj-$(CONFIG_VIDEO_OV7740) += ov7740.o
 obj-$(CONFIG_VIDEO_OV8856) += ov8856.o
+obj-$(CONFIG_VIDEO_OV8865) += ov8865.o
 obj-$(CONFIG_VIDEO_OV9640) += ov9640.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
 obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
diff --git a/drivers/media/i2c/ov8865.c b/drivers/media/i2c/ov8865.c
new file mode 100644
index ..fda5a55979aa
--- /dev/null
+++ b/drivers/media/i2c/ov8865.c
@@ -0,0 +1,2972 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright 2020 Kévin L'hôpital 
+ * Copyright 2020 Bootlin
+ * Author: Paul Kocialkowski 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Clock rate */
+
+#define OV8865_EXTCLK_RATE 2400
+
+/* Register definitions */
+
+/* System */
+
+#define OV8865_SW_STANDBY_REG  0x100
+#define OV8865_SW_STANDBY_STREAM_ONBIT(0)
+
+#define OV8865_SW_RESET_REG0x103
+#define OV8865_SW_RESET_RESET  BIT(0)
+
+#define OV8865_PLL_CTRL0_REG   0x300
+#define OV8865_PLL_CTRL0_PRE_DIV(v)((v) & GENMASK(2, 0))
+#define OV8865_PLL_CTRL1_REG   0x301
+#define OV8865_PLL_CTRL1_MUL_H(v)  (((v) & GENMASK(9, 8)) >> 8)
+#define OV8865_PLL_CTRL2_REG   0x302
+#define OV8865_PLL_CTRL2_MUL_L(v)  ((v) & GENMASK(7, 0))
+#define OV8865_PLL_CTRL3_REG   0x303
+#define OV8865_PLL_CTRL3_M_DIV(v)  (((v) - 1) & GENMASK(3, 0))
+#define OV8865_PLL_CTRL4_REG   0x304
+#define OV8865_PLL_CTRL4_MIPI_DIV(v)   ((v) & GENMASK(1, 0))
+#define OV8865_PLL_CTRL5_REG   0x305
+#define OV8865_PLL_CTRL5_SYS_PRE_DIV(v)((v) & GENMASK(1, 0))
+#define OV8865_PLL_CTRL6_REG   0x306
+#define OV8865_PLL_CTRL6_SYS_DIV(v)(((v) - 1) & BIT(0))
+
+#define OV8865_PLL_CTRL8_REG   0x308
+#define OV8865_PLL_CTRL9_REG   0x309
+#define OV8865_PLL_CTRLA_REG   0x30a
+#define OV8865_PLL_CTRLA_PRE_DIV_HALF(v)   (((v) - 1) & BIT(0))
+#define OV8865_PLL_CTRLB_REG   0x30b
+#define OV8865_PLL_CTRLB_PRE_DIV(v)((v) & GENMASK(2, 0))
+#define OV8865_PLL_CTRLC_REG   0x30c
+#define OV8865_PLL_CTRLC_MUL_H(v)  (((v) & GENMASK(9, 8)) >> 8)
+#define OV8865_PLL_CTRLD_REG   0x30d
+#define OV8865_PLL_CTRLD_MUL_L(v)  ((v) & GENMASK(7, 0))
+#define OV8865_PLL_CTRLE_REG   

[PATCH v4 1/3] dt-bindings: media: i2c: Add OV8865 bindings documentation

2020-12-31 Thread Paul Kocialkowski
This introduces YAML bindings documentation for the OV8865
image sensor.

Co-developed-by: Kévin L'hôpital 
Signed-off-by: Kévin L'hôpital 
Signed-off-by: Paul Kocialkowski 
Reviewed-by: Rob Herring 
---
 .../bindings/media/i2c/ovti,ov8865.yaml   | 124 ++
 1 file changed, 124 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml

diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml 
b/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml
new file mode 100644
index ..c0ba28aa30c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov8865.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OmniVision OV8865 Image Sensor Device Tree Bindings
+
+maintainers:
+  - Paul Kocialkowski 
+
+properties:
+  compatible:
+const: ovti,ov8865
+
+  reg:
+maxItems: 1
+
+  clocks:
+items:
+  - description: EXTCLK Clock
+
+  assigned-clocks:
+maxItems: 1
+
+  assigned-clock-rates:
+maxItems: 1
+
+  dvdd-supply:
+description: Digital Domain Power Supply
+
+  avdd-supply:
+description: Analog Domain Power Supply
+
+  dovdd-supply:
+description: I/O Domain Power Supply
+
+  powerdown-gpios:
+maxItems: 1
+description: Power Down Pin GPIO Control (active low)
+
+  reset-gpios:
+maxItems: 1
+description: Reset Pin GPIO Control (active low)
+
+  port:
+type: object
+description: MIPI CSI-2 transmitter port
+
+properties:
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+  link-frequencies:
+$ref: /schemas/types.yaml#/definitions/uint64-array
+description: Allowed MIPI CSI-2 link frequencies
+
+  data-lanes:
+minItems: 1
+maxItems: 4
+
+required:
+  - data-lanes
+  - link-frequencies
+  - remote-endpoint
+
+required:
+  - endpoint
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - assigned-clocks
+  - assigned-clock-rates
+  - dvdd-supply
+  - avdd-supply
+  - dovdd-supply
+  - port
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+
+i2c2 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+ov8865: camera@36 {
+compatible = "ovti,ov8865";
+reg = <0x36>;
+
+pinctrl-names = "default";
+pinctrl-0 = <_mclk_pin>;
+
+clocks = < CLK_CSI_MCLK>;
+assigned-clocks = < CLK_CSI_MCLK>;
+assigned-clock-rates = <2400>;
+
+avdd-supply = <_ov8865_avdd>;
+dovdd-supply = <_ov8865_dovdd>;
+dvdd-supply = <_ov8865_dvdd>;
+
+powerdown-gpios = < 4 17 GPIO_ACTIVE_LOW>; /* PE17 */
+reset-gpios = < 4 16 GPIO_ACTIVE_LOW>; /* PE16 */
+
+port {
+ov8865_out_mipi_csi2: endpoint {
+data-lanes = <1 2 3 4>;
+link-frequencies = /bits/ 64 <36000>;
+
+remote-endpoint = <_csi2_in_ov8865>;
+};
+};
+};
+};
+
+...
-- 
2.29.2



[PATCH v4 0/3] media: i2c: OV8865 image sensor support

2020-12-31 Thread Paul Kocialkowski
This series adds support for the OV8865 image sensor, as a V4L2 subdev
driver. Although an initial series was submitted by Kévin L'hôpital some
weeks ago, this version is significantly new and should be considered a
new series.

The final patch (not for merge) shows how to enable the OV8865 on the
Banana Pi Camera Board v2 with the Banana Pi M3.

Changes since v3:
- Fixed error label goto after runtime pm calls in probe;
- Fixed variables names in macros using container_of;
- Set ctrls flags after handler error check;
- Removed useless ret initializations and gotos;
- Removed call to v4l2_device_unregister_subdev.

Changes since v2:
- Added link-frequencies endpoint property support;
- Marked avdd-supply as non-optional (no internal regulator);
- Used NULL ctrl ops for pixel rate and link freq;
- Extra cosmetic changes.

Changes since v1:
- Used runtime pm;
- Used assigned-clock-rate;
- Removed clock name;
- Returned closest size in set_fmt;
- Removed unneeded references to v4l2 controls;
- Removed unneeded structure packing attribute;
- Removed i2c device table;
- Dual-licensed bindings;
- Used SPDX tags.

Cheers,

Paul

Kévin L'hôpital (1):
  ARM: dts: sun8i: a83t: bananapi-m3: Enable MIPI CSI-2 with OV8865

Paul Kocialkowski (2):
  dt-bindings: media: i2c: Add OV8865 bindings documentation
  media: i2c: Add support for the OV8865 image sensor

 .../bindings/media/i2c/ovti,ov8865.yaml   |  124 +
 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts  |  102 +
 drivers/media/i2c/Kconfig |   13 +
 drivers/media/i2c/Makefile|1 +
 drivers/media/i2c/ov8865.c| 2972 +
 5 files changed, 3212 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml
 create mode 100644 drivers/media/i2c/ov8865.c

-- 
2.29.2



[PATCH v7 2/2] media: i2c: Add support for the OV5648 image sensor

2020-12-31 Thread Paul Kocialkowski
The OV5648 is a 5 Mpx CMOS image sensor, connected via MIPI CSI-2
in a one or two lane configuration.

Most of the features of the hardware are supported, including:
- Auto and manual exposition/gain
- Auto and manual white balance
- Horizontal and vertical flip
- Test patterns

But the following are still missing:
- Debanding, based on power source frequency;
- Exposition setting correlated to time units.

Signed-off-by: Paul Kocialkowski 
---
 drivers/media/i2c/Kconfig  |   13 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov5648.c | 2623 
 3 files changed, 2637 insertions(+)
 create mode 100644 drivers/media/i2c/ov5648.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 878f66ef2719..c0470a8b9a80 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -922,6 +922,19 @@ config VIDEO_OV5647
  To compile this driver as a module, choose M here: the
  module will be called ov5647.
 
+config VIDEO_OV5648
+   tristate "OmniVision OV5648 sensor support"
+   depends on I2C && PM && VIDEO_V4L2
+   select MEDIA_CONTROLLER
+   select VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+   help
+ This is a Video4Linux2 sensor driver for the OmniVision
+ OV5648 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov5648.
+
 config VIDEO_OV6650
tristate "OmniVision OV6650 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index f0a77473979d..15d4d6382582 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_VIDEO_OV2740) += ov2740.o
 obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
 obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
 obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
+obj-$(CONFIG_VIDEO_OV5648) += ov5648.o
 obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
 obj-$(CONFIG_VIDEO_OV5675) += ov5675.o
 obj-$(CONFIG_VIDEO_OV5695) += ov5695.o
diff --git a/drivers/media/i2c/ov5648.c b/drivers/media/i2c/ov5648.c
new file mode 100644
index ..609aa67b54ce
--- /dev/null
+++ b/drivers/media/i2c/ov5648.c
@@ -0,0 +1,2623 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2020 Bootlin
+ * Author: Paul Kocialkowski 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Clock rate */
+
+#define OV5648_XVCLK_RATE  2400
+
+/* Register definitions */
+
+/* System */
+
+#define OV5648_SW_STANDBY_REG  0x100
+#define OV5648_SW_STANDBY_STREAM_ONBIT(0)
+
+#define OV5648_SW_RESET_REG0x103
+#define OV5648_SW_RESET_RESET  BIT(0)
+
+#define OV5648_PAD_OEN0_REG0x3000
+#define OV5648_PAD_OEN1_REG0x3001
+#define OV5648_PAD_OEN2_REG0x3002
+#define OV5648_PAD_OUT0_REG0x3008
+#define OV5648_PAD_OUT1_REG0x3009
+
+#define OV5648_CHIP_ID_H_REG   0x300a
+#define OV5648_CHIP_ID_H_VALUE 0x56
+#define OV5648_CHIP_ID_L_REG   0x300b
+#define OV5648_CHIP_ID_L_VALUE 0x48
+
+#define OV5648_PAD_OUT2_REG0x300d
+#define OV5648_PAD_SEL0_REG0x300e
+#define OV5648_PAD_SEL1_REG0x300f
+#define OV5648_PAD_SEL2_REG0x3010
+#define OV5648_PAD_PK_REG  0x3011
+#define OV5648_PAD_PK_PD_DATO_EN   BIT(7)
+#define OV5648_PAD_PK_DRIVE_STRENGTH_1X(0 << 5)
+#define OV5648_PAD_PK_DRIVE_STRENGTH_2X(2 << 5)
+#define OV5648_PAD_PK_FREX_N   BIT(1)
+
+#define OV5648_A_PWC_PK_O0_REG 0x3013
+#define OV5648_A_PWC_PK_O0_BP_REGULATOR_N  BIT(3)
+#define OV5648_A_PWC_PK_O1_REG 0x3014
+
+#define OV5648_MIPI_PHY0_REG   0x3016
+#define OV5648_MIPI_PHY1_REG   0x3017
+#define OV5648_MIPI_SC_CTRL0_REG   0x3018
+#define OV5648_MIPI_SC_CTRL0_MIPI_LANES(v) (((v) << 5) & GENMASK(7, 5))
+#define OV5648_MIPI_SC_CTRL0_PHY_HS_TX_PD  BIT(4)
+#define OV5648_MIPI_SC_CTRL0_PHY_LP_RX_PD  BIT(3)
+#define OV5648_MIPI_SC_CTRL0_MIPI_EN   BIT(2)
+#define OV5648_MIPI_SC_CTRL0_MIPI_SUSP BIT(1)
+#define OV5648_MIPI_SC_CTRL0_LANE_DIS_OP   BIT(0)
+#define OV5648_MIPI_SC_CTRL1_REG   0x3019
+#define OV5648_MISC_CTRL0_REG  0x3021
+#define OV5648_MIPI_SC_CTRL2_REG   0x3022
+#define OV5648_SUB_ID_REG  0x302a
+
+#define OV5648_PLL_CTRL0_REG   0x3034
+#define OV5648_PLL_CTRL0_PLL_CHARGE_PUMP(v)(((v) << 4) & GENMASK(6, 4))
+#

[PATCH v7 1/2] dt-bindings: media: i2c: Add OV5648 bindings documentation

2020-12-31 Thread Paul Kocialkowski
This introduces YAML bindings documentation for the OV5648
image sensor.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Rob Herring 
---
 .../bindings/media/i2c/ovti,ov5648.yaml   | 115 ++
 1 file changed, 115 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml

diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml 
b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml
new file mode 100644
index ..f8783f77cc54
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov5648.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OmniVision OV5648 Image Sensor Device Tree Bindings
+
+maintainers:
+  - Paul Kocialkowski 
+
+properties:
+  compatible:
+const: ovti,ov5648
+
+  reg:
+maxItems: 1
+
+  clocks:
+items:
+  - description: XVCLK Clock
+
+  assigned-clocks:
+maxItems: 1
+
+  assigned-clock-rates:
+maxItems: 1
+
+  dvdd-supply:
+description: Digital Domain Power Supply
+
+  avdd-supply:
+description: Analog Domain Power Supply (internal AVDD is used if missing)
+
+  dovdd-supply:
+description: I/O Domain Power Supply
+
+  powerdown-gpios:
+maxItems: 1
+description: Power Down Pin GPIO Control (active low)
+
+  reset-gpios:
+maxItems: 1
+description: Reset Pin GPIO Control (active low)
+
+  port:
+type: object
+description: MIPI CSI-2 transmitter port
+
+properties:
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+  link-frequencies:
+$ref: /schemas/types.yaml#/definitions/uint64-array
+description: Allowed MIPI CSI-2 link frequencies
+
+  data-lanes:
+minItems: 1
+maxItems: 2
+
+required:
+  - data-lanes
+  - link-frequencies
+  - remote-endpoint
+
+required:
+  - endpoint
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - assigned-clocks
+  - assigned-clock-rates
+  - dvdd-supply
+  - dovdd-supply
+  - port
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+ov5648: camera@36 {
+compatible = "ovti,ov5648";
+reg = <0x36>;
+
+dvdd-supply = <_dvdd>;
+avdd-supply = <_avdd>;
+dovdd-supply = <_dovdd>;
+clocks = <_xvclk 0>;
+assigned-clocks = <_xvclk 0>;
+assigned-clock-rates = <2400>;
+
+
+ov5648_out: port {
+ov5648_out_mipi_csi2: endpoint {
+data-lanes = <1 2>;
+link-frequencies = /bits/ 64 <21000 16800>;
+
+remote-endpoint = <_csi2_in_ov5648>;
+};
+};
+};
+};
-- 
2.29.2



[PATCH v7 0/2] media: i2c: OV5648 image sensor support

2020-12-31 Thread Paul Kocialkowski
This series adds support for the OV5648 image sensor,
as a V4L2 subdev driver.

Changes since v6:
- Removed unused ret declaration that caused a build warning.

Changes since v5:
- Removed extra tailing ret checks;
- Fixed variables names in macros using container_of;
- Set ctrls flags after handler error check;
- Removed useless ret initializations and gotos;
- Removed call to v4l2_device_unregister_subdev;

Changes since v4:
- Squashed tailing function calls in return;
- Added Kconfig depend on PM since it's not optional;
- Reordered runtime PM in init;
- Reworked runtime PM order and added ctrls handler free in exit.

Changes since v3:
- Removed mipi_clk_rate variable that skipped through.

Changes since v2:
- Added link-frequencies endpoint property support;
- Used NULL ctrl ops for pixel rate and link freq;
- Extra cosmetic changes.

Changes since v1:
- Used runtime pm;
- Used assigned-clock-rate;
- Removed clock name;
- Returned closest size in set_fmt;
- Removed unneeded references to v4l2 controls;
- Removed i2c device table;
- Dual-licensed bindings;
- Used SPDX tags.

Paul Kocialkowski (2):
  dt-bindings: media: i2c: Add OV5648 bindings documentation
  media: i2c: Add support for the OV5648 image sensor

 .../bindings/media/i2c/ovti,ov5648.yaml   |  115 +
 drivers/media/i2c/Kconfig |   13 +
 drivers/media/i2c/Makefile|1 +
 drivers/media/i2c/ov5648.c| 2623 +
 4 files changed, 2752 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml
 create mode 100644 drivers/media/i2c/ov5648.c

-- 
2.29.2



[PATCH v6 0/2] media: i2c: OV5648 image sensor support

2020-12-31 Thread Paul Kocialkowski
This series adds support for the OV5648 image sensor,
as a V4L2 subdev driver.

Changes since v5:
- Removed extra tailing ret checks;
- Fixed variables names in macros using container_of;
- Set ctrls flags after handler error check;
- Removed useless ret initializations and gotos;
- Removed call to v4l2_device_unregister_subdev;

Changes since v4:
- Squashed tailing function calls in return;
- Added Kconfig depend on PM since it's not optional;
- Reordered runtime PM in init;
- Reworked runtime PM order and added ctrls handler free in exit.

Changes since v3:
- Removed mipi_clk_rate variable that skipped through.

Changes since v2:
- Added link-frequencies endpoint property support;
- Used NULL ctrl ops for pixel rate and link freq;
- Extra cosmetic changes.

Changes since v1:
- Used runtime pm;
- Used assigned-clock-rate;
- Removed clock name;
- Returned closest size in set_fmt;
- Removed unneeded references to v4l2 controls;
- Removed i2c device table;
- Dual-licensed bindings;
- Used SPDX tags.

Paul Kocialkowski (2):
  dt-bindings: media: i2c: Add OV5648 bindings documentation
  media: i2c: Add support for the OV5648 image sensor

 .../bindings/media/i2c/ovti,ov5648.yaml   |  115 +
 drivers/media/i2c/Kconfig |   13 +
 drivers/media/i2c/Makefile|1 +
 drivers/media/i2c/ov5648.c| 2624 +
 4 files changed, 2753 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml
 create mode 100644 drivers/media/i2c/ov5648.c

-- 
2.29.2



[PATCH v6 2/2] media: i2c: Add support for the OV5648 image sensor

2020-12-31 Thread Paul Kocialkowski
The OV5648 is a 5 Mpx CMOS image sensor, connected via MIPI CSI-2
in a one or two lane configuration.

Most of the features of the hardware are supported, including:
- Auto and manual exposition/gain
- Auto and manual white balance
- Horizontal and vertical flip
- Test patterns

But the following are still missing:
- Debanding, based on power source frequency;
- Exposition setting correlated to time units.

Signed-off-by: Paul Kocialkowski 
---
 drivers/media/i2c/Kconfig  |   13 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov5648.c | 2624 
 3 files changed, 2638 insertions(+)
 create mode 100644 drivers/media/i2c/ov5648.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 878f66ef2719..c0470a8b9a80 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -922,6 +922,19 @@ config VIDEO_OV5647
  To compile this driver as a module, choose M here: the
  module will be called ov5647.
 
+config VIDEO_OV5648
+   tristate "OmniVision OV5648 sensor support"
+   depends on I2C && PM && VIDEO_V4L2
+   select MEDIA_CONTROLLER
+   select VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+   help
+ This is a Video4Linux2 sensor driver for the OmniVision
+ OV5648 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov5648.
+
 config VIDEO_OV6650
tristate "OmniVision OV6650 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index f0a77473979d..15d4d6382582 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_VIDEO_OV2740) += ov2740.o
 obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
 obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
 obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
+obj-$(CONFIG_VIDEO_OV5648) += ov5648.o
 obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
 obj-$(CONFIG_VIDEO_OV5675) += ov5675.o
 obj-$(CONFIG_VIDEO_OV5695) += ov5695.o
diff --git a/drivers/media/i2c/ov5648.c b/drivers/media/i2c/ov5648.c
new file mode 100644
index ..8c3dc483f14e
--- /dev/null
+++ b/drivers/media/i2c/ov5648.c
@@ -0,0 +1,2624 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2020 Bootlin
+ * Author: Paul Kocialkowski 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Clock rate */
+
+#define OV5648_XVCLK_RATE  2400
+
+/* Register definitions */
+
+/* System */
+
+#define OV5648_SW_STANDBY_REG  0x100
+#define OV5648_SW_STANDBY_STREAM_ONBIT(0)
+
+#define OV5648_SW_RESET_REG0x103
+#define OV5648_SW_RESET_RESET  BIT(0)
+
+#define OV5648_PAD_OEN0_REG0x3000
+#define OV5648_PAD_OEN1_REG0x3001
+#define OV5648_PAD_OEN2_REG0x3002
+#define OV5648_PAD_OUT0_REG0x3008
+#define OV5648_PAD_OUT1_REG0x3009
+
+#define OV5648_CHIP_ID_H_REG   0x300a
+#define OV5648_CHIP_ID_H_VALUE 0x56
+#define OV5648_CHIP_ID_L_REG   0x300b
+#define OV5648_CHIP_ID_L_VALUE 0x48
+
+#define OV5648_PAD_OUT2_REG0x300d
+#define OV5648_PAD_SEL0_REG0x300e
+#define OV5648_PAD_SEL1_REG0x300f
+#define OV5648_PAD_SEL2_REG0x3010
+#define OV5648_PAD_PK_REG  0x3011
+#define OV5648_PAD_PK_PD_DATO_EN   BIT(7)
+#define OV5648_PAD_PK_DRIVE_STRENGTH_1X(0 << 5)
+#define OV5648_PAD_PK_DRIVE_STRENGTH_2X(2 << 5)
+#define OV5648_PAD_PK_FREX_N   BIT(1)
+
+#define OV5648_A_PWC_PK_O0_REG 0x3013
+#define OV5648_A_PWC_PK_O0_BP_REGULATOR_N  BIT(3)
+#define OV5648_A_PWC_PK_O1_REG 0x3014
+
+#define OV5648_MIPI_PHY0_REG   0x3016
+#define OV5648_MIPI_PHY1_REG   0x3017
+#define OV5648_MIPI_SC_CTRL0_REG   0x3018
+#define OV5648_MIPI_SC_CTRL0_MIPI_LANES(v) (((v) << 5) & GENMASK(7, 5))
+#define OV5648_MIPI_SC_CTRL0_PHY_HS_TX_PD  BIT(4)
+#define OV5648_MIPI_SC_CTRL0_PHY_LP_RX_PD  BIT(3)
+#define OV5648_MIPI_SC_CTRL0_MIPI_EN   BIT(2)
+#define OV5648_MIPI_SC_CTRL0_MIPI_SUSP BIT(1)
+#define OV5648_MIPI_SC_CTRL0_LANE_DIS_OP   BIT(0)
+#define OV5648_MIPI_SC_CTRL1_REG   0x3019
+#define OV5648_MISC_CTRL0_REG  0x3021
+#define OV5648_MIPI_SC_CTRL2_REG   0x3022
+#define OV5648_SUB_ID_REG  0x302a
+
+#define OV5648_PLL_CTRL0_REG   0x3034
+#define OV5648_PLL_CTRL0_PLL_CHARGE_PUMP(v)(((v) << 4) & GENMASK(6, 4))
+#

[PATCH v6 1/2] dt-bindings: media: i2c: Add OV5648 bindings documentation

2020-12-31 Thread Paul Kocialkowski
This introduces YAML bindings documentation for the OV5648
image sensor.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Rob Herring 
---
 .../bindings/media/i2c/ovti,ov5648.yaml   | 115 ++
 1 file changed, 115 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml

diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml 
b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml
new file mode 100644
index ..f8783f77cc54
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov5648.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OmniVision OV5648 Image Sensor Device Tree Bindings
+
+maintainers:
+  - Paul Kocialkowski 
+
+properties:
+  compatible:
+const: ovti,ov5648
+
+  reg:
+maxItems: 1
+
+  clocks:
+items:
+  - description: XVCLK Clock
+
+  assigned-clocks:
+maxItems: 1
+
+  assigned-clock-rates:
+maxItems: 1
+
+  dvdd-supply:
+description: Digital Domain Power Supply
+
+  avdd-supply:
+description: Analog Domain Power Supply (internal AVDD is used if missing)
+
+  dovdd-supply:
+description: I/O Domain Power Supply
+
+  powerdown-gpios:
+maxItems: 1
+description: Power Down Pin GPIO Control (active low)
+
+  reset-gpios:
+maxItems: 1
+description: Reset Pin GPIO Control (active low)
+
+  port:
+type: object
+description: MIPI CSI-2 transmitter port
+
+properties:
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+  link-frequencies:
+$ref: /schemas/types.yaml#/definitions/uint64-array
+description: Allowed MIPI CSI-2 link frequencies
+
+  data-lanes:
+minItems: 1
+maxItems: 2
+
+required:
+  - data-lanes
+  - link-frequencies
+  - remote-endpoint
+
+required:
+  - endpoint
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - assigned-clocks
+  - assigned-clock-rates
+  - dvdd-supply
+  - dovdd-supply
+  - port
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+ov5648: camera@36 {
+compatible = "ovti,ov5648";
+reg = <0x36>;
+
+dvdd-supply = <_dvdd>;
+avdd-supply = <_avdd>;
+dovdd-supply = <_dovdd>;
+clocks = <_xvclk 0>;
+assigned-clocks = <_xvclk 0>;
+assigned-clock-rates = <2400>;
+
+
+ov5648_out: port {
+ov5648_out_mipi_csi2: endpoint {
+data-lanes = <1 2>;
+link-frequencies = /bits/ 64 <21000 16800>;
+
+remote-endpoint = <_csi2_in_ov5648>;
+};
+};
+};
+};
-- 
2.29.2



Re: [PATCH v3 09/15] media: sunxi: Add support for the A31 MIPI CSI-2 controller

2020-12-31 Thread Paul Kocialkowski
Hi,

On Mon 14 Dec 20, 12:39, Maxime Ripard wrote:
> On Fri, Dec 11, 2020 at 04:57:02PM +0100, Paul Kocialkowski wrote:
> > +#define sun6i_mipi_csi2_subdev_video(subdev) \
> > +   container_of(subdev, struct sun6i_mipi_csi2_video, subdev)
> > +
> > +#define sun6i_mipi_csi2_video_dev(video) \
> > +   container_of(video, struct sun6i_mipi_csi2_dev, video)
> 
> Isn't it a bit unsafe?
> 
> The second subdev and video here is not the variable passed in the macro
> but the field in the structure, so any attempt at using those two macros
> with anything but a variable named subdev or video will result in a
> compilation issue?

Yep you're totally right. Will fix in the next revision!

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH v5 2/2] media: i2c: Add support for the OV5648 image sensor

2020-12-31 Thread Paul Kocialkowski
Hi Sakari,

On Mon 21 Dec 20, 00:39, Sakari Ailus wrote:
> Hi Paul,
> 
> Thanks for the update.
> 
> A few more small issues below that I didn't notice earlier. The comments
> apply to the other driver as well I believe.

Thanks for the review, I'll address your comments in the next version for
both drivers!

Cheers,

Paul

> On Fri, Dec 11, 2020 at 04:40:27PM +0100, Paul Kocialkowski wrote:
> > The OV5648 is a 5 Mpx CMOS image sensor, connected via MIPI CSI-2
> > in a one or two lane configuration.
> > 
> > Most of the features of the hardware are supported, including:
> > - Auto and manual exposition/gain
> > - Auto and manual white balance
> > - Horizontal and vertical flip
> > - Test patterns
> > 
> > But the following are still missing:
> > - Debanding, based on power source frequency;
> > - Exposition setting correlated to time units.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  drivers/media/i2c/Kconfig  |   13 +
> >  drivers/media/i2c/Makefile |1 +
> >  drivers/media/i2c/ov5648.c | 2638 
> >  3 files changed, 2652 insertions(+)
> >  create mode 100644 drivers/media/i2c/ov5648.c
> > 
> > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> > index 878f66ef2719..c0470a8b9a80 100644
> > --- a/drivers/media/i2c/Kconfig
> > +++ b/drivers/media/i2c/Kconfig
> > @@ -922,6 +922,19 @@ config VIDEO_OV5647
> >   To compile this driver as a module, choose M here: the
> >   module will be called ov5647.
> >  
> > +config VIDEO_OV5648
> > +   tristate "OmniVision OV5648 sensor support"
> > +   depends on I2C && PM && VIDEO_V4L2
> > +   select MEDIA_CONTROLLER
> > +   select VIDEO_V4L2_SUBDEV_API
> > +   select V4L2_FWNODE
> > +   help
> > + This is a Video4Linux2 sensor driver for the OmniVision
> > + OV5648 camera.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called ov5648.
> > +
> >  config VIDEO_OV6650
> > tristate "OmniVision OV6650 sensor support"
> > depends on I2C && VIDEO_V4L2
> > diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> > index f0a77473979d..15d4d6382582 100644
> > --- a/drivers/media/i2c/Makefile
> > +++ b/drivers/media/i2c/Makefile
> > @@ -71,6 +71,7 @@ obj-$(CONFIG_VIDEO_OV2740) += ov2740.o
> >  obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
> >  obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
> >  obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
> > +obj-$(CONFIG_VIDEO_OV5648) += ov5648.o
> >  obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
> >  obj-$(CONFIG_VIDEO_OV5675) += ov5675.o
> >  obj-$(CONFIG_VIDEO_OV5695) += ov5695.o
> > diff --git a/drivers/media/i2c/ov5648.c b/drivers/media/i2c/ov5648.c
> > new file mode 100644
> > index ..4ae6b65ec258
> > --- /dev/null
> > +++ b/drivers/media/i2c/ov5648.c
> > @@ -0,0 +1,2638 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright (C) 2020 Bootlin
> > + * Author: Paul Kocialkowski 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/* Clock rate */
> > +
> > +#define OV5648_XVCLK_RATE  2400
> > +
> > +/* Register definitions */
> > +
> > +/* System */
> > +
> > +#define OV5648_SW_STANDBY_REG  0x100
> > +#define OV5648_SW_STANDBY_STREAM_ONBIT(0)
> > +
> > +#define OV5648_SW_RESET_REG0x103
> > +#define OV5648_SW_RESET_RESET  BIT(0)
> > +
> > +#define OV5648_PAD_OEN0_REG0x3000
> > +#define OV5648_PAD_OEN1_REG0x3001
> > +#define OV5648_PAD_OEN2_REG0x3002
> > +#define OV5648_PAD_OUT0_REG0x3008
> > +#define OV5648_PAD_OUT1_REG0x3009
> > +
> > +#define OV5648_CHIP_ID_H_REG   0x300a
> > +#define OV5648_CHIP_ID_H_VALUE 0x56
> > +#define OV5648_CHIP_ID_L_REG   0x300b
> > +#define OV5648_CHIP_ID_L_VALUE 0x48
> > +
> > +#define OV5648_PAD_OUT2_REG0x300d
> > +#define OV5648_PAD_SEL0_

Re: [PATCH v2 1/2] usb: ohci: Default to per-port over-current protection

2020-12-27 Thread Paul Kocialkowski
Hi,

On Fri 11 Sep 20, 09:25, Hamish Martin wrote:
> Some integrated OHCI controller hubs do not expose all ports of the hub
> to pins on the SoC. In some cases the unconnected ports generate
> spurious over-current events. For example the Broadcom 56060/Ranger 2 SoC
> contains a nominally 3 port hub but only the first port is wired.
> 
> Default behaviour for ohci-platform driver is to use global over-current
> protection mode (AKA "ganged"). This leads to the spurious over-current
> events affecting all ports in the hub.
> 
> We now alter the default to use per-port over-current protection.

This specific patch lead to breaking OHCI on my mom's laptop (whom was about
to buy a new one thinking the hardware had failed). I get no OHCI interrupt at
all and no USB 1 device is ever detected.

I haven't really found a reasonable explanation about why that is, but here
are some notes I was able to collect:
- The issue showed up on 5.8,18 and 5.9.15, which don't include the patch
  from this series that sets distrust_firmware = false; This results in the NPS
  bit being set via OHCI_QUIRK_HUB_POWER.
- Adding val &= ~RH_A_PSM; (as was done before this change) solves the issue
  which is weird because the bit is supposed to be inactive when NPS is set;
- Setting ohci_hcd.distrust_firmware=0 in the cmdline results in not setting
  the NPS bit and also solves the issue;
- The initial value of the register at function entry is 0x1001104 (PSM bit
  is set, NPS is unset);
- The OHCI controller is the following:
00:03.0 USB controller: Silicon Integrated Systems [SiS] USB 1.1 Controller 
(rev 0f) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc. Device 1aa7

Does that make any sense to you?

I really wonder what a proper fix could be and here are some suggestions:
- Adding a specific quirk to clear the PSM bit for this hardware which seems to
  consider the bit regardless of NPS;
- Adding the patch that sets distrust_firmware = false to stable branches;

What do you think?

Cheers,

Paul

> This patch results in the following configuration changes depending
> on quirks:
> - For quirk OHCI_QUIRK_SUPERIO no changes. These systems remain set up
>   for ganged power switching and no over-current protection.
> - For quirk OHCI_QUIRK_AMD756 or OHCI_QUIRK_HUB_POWER power switching
>   remains at none, while over-current protection is now guaranteed to be
>   set to per-port rather than the previous behaviour where it was either
>   none or global over-current protection depending on the value at
>   function entry.
> 
> Suggested-by: Alan Stern 
> Signed-off-by: Hamish Martin 
> ---
> 
> Notes:
> Changes in v2:
> - remove clearing of RH_A_PSM in OHCI_QUIRK_HUB_POWER block.
> 
>  drivers/usb/host/ohci-hcd.c | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
> index dd37e77dae00..2845ea328a06 100644
> --- a/drivers/usb/host/ohci-hcd.c
> +++ b/drivers/usb/host/ohci-hcd.c
> @@ -673,20 +673,24 @@ static int ohci_run (struct ohci_hcd *ohci)
>  
>   /* handle root hub init quirks ... */
>   val = roothub_a (ohci);
> - val &= ~(RH_A_PSM | RH_A_OCPM);
> + /* Configure for per-port over-current protection by default */
> + val &= ~RH_A_NOCP;
> + val |= RH_A_OCPM;
>   if (ohci->flags & OHCI_QUIRK_SUPERIO) {
> - /* NSC 87560 and maybe others */
> + /* NSC 87560 and maybe others.
> +  * Ganged power switching, no over-current protection.
> +  */
>   val |= RH_A_NOCP;
> - val &= ~(RH_A_POTPGT | RH_A_NPS);
> - ohci_writel (ohci, val, >regs->roothub.a);
> + val &= ~(RH_A_POTPGT | RH_A_NPS | RH_A_PSM | RH_A_OCPM);
>   } else if ((ohci->flags & OHCI_QUIRK_AMD756) ||
>   (ohci->flags & OHCI_QUIRK_HUB_POWER)) {
>   /* hub power always on; required for AMD-756 and some
> -  * Mac platforms.  ganged overcurrent reporting, if any.
> +  * Mac platforms.
>*/
>   val |= RH_A_NPS;
> - ohci_writel (ohci, val, >regs->roothub.a);
>   }
> + ohci_writel(ohci, val, >regs->roothub.a);
> +
>   ohci_writel (ohci, RH_HS_LPSC, >regs->roothub.status);
>   ohci_writel (ohci, (val & RH_A_NPS) ? 0 : RH_B_PPCM,
>   >regs->roothub.b);
> -- 
> 2.28.0
> 

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH v8 1/4] dt-bindings: display: Document the Xylon LogiCVC display controller

2020-12-25 Thread Paul Kocialkowski
Hi,

On Thu 24 Dec 20, 10:01, Rob Herring wrote:
> On Wed, 23 Dec 2020 22:29:44 +0100, Paul Kocialkowski wrote:
> > The Xylon LogiCVC is a display controller implemented as programmable
> > logic in Xilinx FPGAs.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > Acked-by: Rob Herring 
> > ---
> >  .../display/xylon,logicvc-display.yaml| 313 ++
> >  1 file changed, 313 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml
> > 
> 
> My bot found errors running 'make dt_binding_check' on your patch:
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/xylon,logicvc-display.example.dt.yaml:
>  logicvc@43c0: 'display@0' does not match any of the regexes: 
> '^gpio@[0-9a-f]+$', 'pinctrl-[0-9]+'
>   From schema: 
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml
> 
> See https://patchwork.ozlabs.org/patch/1420307

Just so you know, this specific issue is fixed in patch 2/4.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH v2 1/2] dt-bindings: pwm: allwinner: Add V3s compatible description

2020-12-24 Thread Paul Kocialkowski
Hi,

Le Tue 22 Dec 20, 09:21, Jernej Škrabec a écrit :
> Dne petek, 18. december 2020 ob 21:54:35 CET je Paul Kocialkowski napisal(a):
> > Introduce bindings description for the V3s PWM, which is
> > register-compatible with the A20 PWM.
> > 
> > Signed-off-by: Paul Kocialkowski 
> 
> This is meant to be used together with V3s PWM patch you recently send? Can 
> you please resend them together, with fixed compatible in DT node? Currently 
> it's not clear why this patch is needed and PWM patch will need fix anyway.

I've sent them together (this one is v2 1/2 and 2/2 is the PWM dt patch).

You can grab it at: https://lore.kernel.org/patchwork/patch/1355289/
if it didn't reach your emails.

Cheers,

Paul

> > ---
> >  .../devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml   | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml
> > b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml index
> > 7dcab2bf8128..04ff708fdc86 100644
> > --- a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml
> > +++ b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml
> > @@ -24,6 +24,9 @@ properties:
> >- items:
> >- const: allwinner,sun8i-a83t-pwm
> >- const: allwinner,sun8i-h3-pwm
> > +  - items:
> > +  - const: allwinner,sun8i-v3s-pwm
> > +  - const: allwinner,sun7i-a20-pwm
> >- items:
> >- const: allwinner,sun50i-a64-pwm
> >- const: allwinner,sun5i-a13-pwm
> 
> 
> 
> 

-- 
Developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/


signature.asc
Description: PGP signature


Re: [PATCH] ARM: dts: sun8i-v3s: Add CSI0 MCLK pin definition

2020-12-24 Thread Paul Kocialkowski
Hi,

Le Tue 22 Dec 20, 09:17, Jernej Škrabec a écrit :
> Dne petek, 18. december 2020 ob 20:50:33 CET je Paul Kocialkowski napisal(a):
> > This adds a device-tree definition for the CSI0 MCLK pin,
> > which can be used for feeding MIPI CSI-2 sensors.
> > 
> > Signed-off-by: Paul Kocialkowski 
> 
> Is this used anywhere? Current policy is to add pin definitions only if any 
> user exists.

Ah right, sorry. I'll resend this when adding a board that uses it!

Cheers,

Paul

> Best regards,
> Jernej
> 
> > ---
> >  arch/arm/boot/dts/sun8i-v3s.dtsi | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi
> > b/arch/arm/boot/dts/sun8i-v3s.dtsi index a9f5795d4e57..bff822b9fa01 100644
> > --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> > @@ -337,6 +337,12 @@ pio: pinctrl@1c20800 {
> > interrupt-controller;
> > #interrupt-cells = <3>;
> > 
> > +   /omit-if-no-ref/
> > +   csi0_mclk_pin: csi0-mclk-pin {
> > +   pins = "PE20";
> > +   function = "csi_mipi";
> > +   };
> > +
> > /omit-if-no-ref/
> > csi1_8bit_pins: csi1-8bit-pins {
> > pins = "PE0", "PE2", "PE3", 
> "PE8", "PE9",
> 
> 
> 
> 

-- 
Developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/


signature.asc
Description: PGP signature


[PATCH v8 0/4] drm: LogiCVC display controller support

2020-12-23 Thread Paul Kocialkowski
This series introduces support for the LogiCVC display controller.
The controller is a bit unusual since it is usually loaded as
programmable logic on Xilinx FPGAs or Zynq-7000 SoCs.
More details are presented on the main commit for the driver.

More information about the controller is available on the dedicated
web page: https://www.logicbricks.com/Products/logiCVC-ML.aspx

Note that this driver has rather simple connector management, which was
not converted to drm_panel_bridge to keep the ability to enable the panel
at first vblank but also to support DVI.

Change since v7:
- Replaced DRM_INFO/DRM_ERROR/DRM_DEBUG_DRIVER with fashions using drm_device;
- Fixed yaml binding alignment issue;
- Renamed logicvc-display name to the generic "display" name;
- Added patternProperties match for display in the parent mfd binding;
- Used drm_atomic_get_new_crtc_state when needed;
- Checked mode in mode_valid instead of atomic_check;
- Switched to drmm_mode_config_init;
- Removed useless logicvc_connector_destroy wrapper;
- Removed useless drm_dev_put calls;
- Removed atomic_commit_tail that enables the panel and streamlined the logic;
- Reworked Makefile cosmetics;
- Fixed checkpatch issues.

Changes since v6:
- Updated to the latest DRM internal API changes; 
- Used an enum to index dt properties instead of the name string.

Changes since v5:
- Subclass DRM device and use devm_drm_dev_alloc for allocation;
- Removed call to drm_mode_config_cleanup (done automatically with devm);
- Some related code cleanups;
- Bring back not-for-merge patch adding colorkey support.

Changes since v4:
- Updated to internal DRM API changes (rebased on drm-misc-next);
- Added Kconfig dependency on OF;
- Added MAINTAINERS entry;
- Used drm_err and dev_err instead of DRM_ERROR where possible;
- Various cosmetic changes.

Changes since v3:
- Rebased on latest drm-misc;
- Improved event lock wrapping;
- Added collect tag;
- Added color-key support patch (not for merge, for reference only).

Changes since v2:
- Fixed and slightly improved dt schema.

Changes since v1:
- Switched dt bindings documentation to dt schema;
- Described more possible dt parameters;
- Added support for the lvds-3bit interface;
- Added support for grabbing syscon regmap from parent node;
- Removed layers count property and count layers child nodes instead.

Paul Kocialkowski (4):
  dt-bindings: display: Document the Xylon LogiCVC display controller
  dt-bindings: mfd: logicvc: Add patternProperties for the display
  drm: Add support for the LogiCVC display controller
  NOTFORMERGE: drm/logicvc: Add plane colorkey support

 .../display/xylon,logicvc-display.yaml| 313 +++
 .../bindings/mfd/xylon,logicvc.yaml   |   3 +
 MAINTAINERS   |   6 +
 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/logicvc/Kconfig   |   9 +
 drivers/gpu/drm/logicvc/Makefile  |   9 +
 drivers/gpu/drm/logicvc/logicvc_crtc.c| 280 +++
 drivers/gpu/drm/logicvc/logicvc_crtc.h|  21 +
 drivers/gpu/drm/logicvc/logicvc_drm.c | 474 +++
 drivers/gpu/drm/logicvc/logicvc_drm.h |  67 ++
 drivers/gpu/drm/logicvc/logicvc_interface.c   | 214 +
 drivers/gpu/drm/logicvc/logicvc_interface.h   |  28 +
 drivers/gpu/drm/logicvc/logicvc_layer.c   | 762 ++
 drivers/gpu/drm/logicvc/logicvc_layer.h   |  71 ++
 drivers/gpu/drm/logicvc/logicvc_mode.c|  80 ++
 drivers/gpu/drm/logicvc/logicvc_mode.h|  15 +
 drivers/gpu/drm/logicvc/logicvc_of.c  | 185 +
 drivers/gpu/drm/logicvc/logicvc_of.h  |  46 ++
 drivers/gpu/drm/logicvc/logicvc_regs.h|  88 ++
 20 files changed, 2674 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml
 create mode 100644 drivers/gpu/drm/logicvc/Kconfig
 create mode 100644 drivers/gpu/drm/logicvc/Makefile
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_crtc.c
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_crtc.h
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_drm.c
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_drm.h
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_interface.c
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_interface.h
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_layer.c
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_layer.h
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_mode.c
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_mode.h
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_of.c
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_of.h
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_regs.h

-- 
2.29.2



[PATCH v8 3/4] drm: Add support for the LogiCVC display controller

2020-12-23 Thread Paul Kocialkowski
Introduces a driver for the LogiCVC display controller, a programmable
logic controller optimized for use in Xilinx Zynq-7000 SoCs and other
Xilinx FPGAs. The controller is mostly configured at logic synthesis
time so only a subset of configuration is left for the driver to
handle.

The following features are implemented and tested:
- LVDS 4-bit interface;
- RGB565 pixel formats;
- Multiple layers and hardware composition;
- Layer-wide alpha mode;

The following features are implemented but untested:
- Other RGB pixel formats;
- Layer framebuffer configuration for version 4;
- Lowest-layer used as background color;
- Per-pixel alpha mode.

The following features are not implemented:
- YUV pixel formats;
- DVI, LVDS 3-bit, ITU656 and camera link interfaces;
- External parallel input for layer;
- Color-keying;
- LUT-based alpha modes.

Additional implementation-specific notes:
- Panels are only enabled after the first page flip to avoid flashing a
  white screen.
- Depth used in context of the LogiCVC driver only counts color components
  to match the definition of the synthesis parameters.

Support is implemented for both version 3 and 4 of the controller.

With version 3, framebuffers are stored in a dedicated contiguous
memory area, with a base address hardcoded for each layer. This requires
using a dedicated CMA pool registered at the base address and tweaking a
few offset-related registers to try to use any buffer allocated from
the pool. This is done on a best-effort basis to have the hardware cope
with the DRM framebuffer allocation model and there is no guarantee
that each buffer allocated by GEM CMA can be used for any layer.
In particular, buffers allocated below the base address for a layer are
guaranteed not to be configurable for that layer. See the implementation of
logicvc_layer_buffer_find_setup for specifics.

Version 4 allows configuring each buffer address directly, which
guarantees that any buffer can be configured.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Maxime Ripard 
---
 MAINTAINERS |   6 +
 drivers/gpu/drm/Kconfig |   2 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/logicvc/Kconfig |   9 +
 drivers/gpu/drm/logicvc/Makefile|   9 +
 drivers/gpu/drm/logicvc/logicvc_crtc.c  | 280 +
 drivers/gpu/drm/logicvc/logicvc_crtc.h  |  21 +
 drivers/gpu/drm/logicvc/logicvc_drm.c   | 474 +++
 drivers/gpu/drm/logicvc/logicvc_drm.h   |  64 ++
 drivers/gpu/drm/logicvc/logicvc_interface.c | 214 +++
 drivers/gpu/drm/logicvc/logicvc_interface.h |  28 +
 drivers/gpu/drm/logicvc/logicvc_layer.c | 624 
 drivers/gpu/drm/logicvc/logicvc_layer.h |  64 ++
 drivers/gpu/drm/logicvc/logicvc_mode.c  |  80 +++
 drivers/gpu/drm/logicvc/logicvc_mode.h  |  15 +
 drivers/gpu/drm/logicvc/logicvc_of.c| 185 ++
 drivers/gpu/drm/logicvc/logicvc_of.h|  46 ++
 drivers/gpu/drm/logicvc/logicvc_regs.h  |  88 +++
 18 files changed, 2210 insertions(+)
 create mode 100644 drivers/gpu/drm/logicvc/Kconfig
 create mode 100644 drivers/gpu/drm/logicvc/Makefile
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_crtc.c
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_crtc.h
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_drm.c
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_drm.h
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_interface.c
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_interface.h
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_layer.c
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_layer.h
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_mode.c
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_mode.h
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_of.c
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_of.h
 create mode 100644 drivers/gpu/drm/logicvc/logicvc_regs.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 17b92e6a0f06..ba751cef777f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5534,6 +5534,12 @@ S:   Orphan / Obsolete
 F: drivers/gpu/drm/i810/
 F: include/uapi/drm/i810_drm.h
 
+DRM DRIVER FOR LOGICVC DISPLAY CONTROLLER
+M: Paul Kocialkowski 
+S: Supported
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: drivers/gpu/drm/logicvc/
+
 DRM DRIVER FOR LVDS PANELS
 M: Laurent Pinchart 
 L: dri-de...@lists.freedesktop.org
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 0973f408d75f..371970d9b59b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -356,6 +356,8 @@ source "drivers/gpu/drm/arc/Kconfig"
 
 source "drivers/gpu/drm/hisilicon/Kconfig"
 
+source "drivers/gpu/drm/logicvc/Kconfig"
+
 source "drivers/gpu/drm/mediatek/Kconfig"
 
 source "drivers/gpu/drm/zte/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index fefaf

[PATCH v8 2/4] dt-bindings: mfd: logicvc: Add patternProperties for the display

2020-12-23 Thread Paul Kocialkowski
The LogiCVC multi-function device has a display part which is now
described in its binding. Add a patternProperties match for it.

Signed-off-by: Paul Kocialkowski 
---
 Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml 
b/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml
index 8a1a6625c782..9efd49c39bd2 100644
--- a/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml
+++ b/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml
@@ -46,6 +46,9 @@ patternProperties:
   "^gpio@[0-9a-f]+$":
 $ref: /schemas/gpio/xylon,logicvc-gpio.yaml#
 
+  "^display@[0-9a-f]+$":
+$ref: /schemas/display/xylon,logicvc-display.yaml#
+
 required:
   - compatible
   - reg
-- 
2.29.2



[PATCH v8 4/4] NOTFORMERGE: drm/logicvc: Add plane colorkey support

2020-12-23 Thread Paul Kocialkowski
Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/logicvc/logicvc_drm.h   |   3 +
 drivers/gpu/drm/logicvc/logicvc_layer.c | 150 +++-
 drivers/gpu/drm/logicvc/logicvc_layer.h |   7 ++
 3 files changed, 154 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/logicvc/logicvc_drm.h 
b/drivers/gpu/drm/logicvc/logicvc_drm.h
index 68bbac6c4ab9..d69a686ab0f1 100644
--- a/drivers/gpu/drm/logicvc/logicvc_drm.h
+++ b/drivers/gpu/drm/logicvc/logicvc_drm.h
@@ -59,6 +59,9 @@ struct logicvc_drm {
struct list_head layers_list;
struct logicvc_crtc *crtc;
struct logicvc_interface *interface;
+
+   struct drm_property *colorkey_enabled_property;
+   struct drm_property *colorkey_value_property;
 };
 
 #endif
diff --git a/drivers/gpu/drm/logicvc/logicvc_layer.c 
b/drivers/gpu/drm/logicvc/logicvc_layer.c
index 313043d29128..e2c3140926f1 100644
--- a/drivers/gpu/drm/logicvc/logicvc_layer.c
+++ b/drivers/gpu/drm/logicvc/logicvc_layer.c
@@ -23,6 +23,8 @@
 
 #define logicvc_layer(p) \
container_of(p, struct logicvc_layer, drm_plane)
+#define logicvc_layer_state(p) \
+   container_of(p, struct logicvc_layer_state, drm_plane_state)
 
 static uint32_t logicvc_layer_formats_rgb16[] = {
DRM_FORMAT_RGB565,
@@ -138,6 +140,7 @@ static void logicvc_plane_atomic_update(struct drm_plane 
*drm_plane,
struct logicvc_drm *logicvc = logicvc_drm(drm_plane->dev);
struct drm_device *drm_dev = >drm_dev;
struct drm_plane_state *state = drm_plane->state;
+   struct logicvc_layer_state *layer_state = logicvc_layer_state(state);
struct drm_crtc *drm_crtc = >crtc->drm_crtc;
struct drm_display_mode *mode = _crtc->state->adjusted_mode;
struct drm_framebuffer *fb = state->fb;
@@ -214,6 +217,15 @@ static void logicvc_plane_atomic_update(struct drm_plane 
*drm_plane,
 alpha);
}
 
+   /* Layer colorkey */
+
+   if (layer_state->colorkey_enabled) {
+   reg = layer_state->colorkey_value;
+
+   regmap_write(logicvc->regmap,
+LOGICVC_LAYER_COLOR_KEY_REG(index), reg);
+   }
+
/* Layer control */
 
reg = LOGICVC_LAYER_CTRL_ENABLE;
@@ -221,7 +233,8 @@ static void logicvc_plane_atomic_update(struct drm_plane 
*drm_plane,
if (logicvc_layer_format_inverted(fb->format->format))
reg |= LOGICVC_LAYER_CTRL_PIXEL_FORMAT_INVERT;
 
-   reg |= LOGICVC_LAYER_CTRL_COLOR_KEY_DISABLE;
+   if (!layer_state->colorkey_enabled)
+   reg |= LOGICVC_LAYER_CTRL_COLOR_KEY_DISABLE;
 
regmap_write(logicvc->regmap, LOGICVC_LAYER_CTRL_REG(index), reg);
 }
@@ -242,13 +255,109 @@ static struct drm_plane_helper_funcs 
logicvc_plane_helper_funcs = {
.atomic_disable = logicvc_plane_atomic_disable,
 };
 
+static void logicvc_plane_reset(struct drm_plane *drm_plane)
+{
+   struct logicvc_drm *logicvc = logicvc_drm(drm_plane->dev);
+   struct device *dev = logicvc->drm_dev.dev;
+   struct logicvc_layer_state *layer_state;
+
+   if (drm_plane->state) {
+   layer_state = logicvc_layer_state(drm_plane->state);
+   __drm_atomic_helper_plane_destroy_state(drm_plane->state);
+   devm_kfree(dev, layer_state);
+   drm_plane->state = NULL;
+   }
+
+   layer_state = devm_kzalloc(dev, sizeof(*layer_state), GFP_KERNEL);
+   if (!layer_state)
+   return;
+
+   __drm_atomic_helper_plane_reset(drm_plane,
+   _state->drm_plane_state);
+}
+
+static struct drm_plane_state *
+logicvc_plane_atomic_duplicate_state(struct drm_plane *drm_plane)
+{
+   struct logicvc_drm *logicvc = logicvc_drm(drm_plane->dev);
+   struct device *dev = logicvc->drm_dev.dev;
+   struct logicvc_layer_state *layer_state_current;
+   struct logicvc_layer_state *layer_state;
+
+   if (WARN_ON(!drm_plane->state))
+   return NULL;
+
+   layer_state_current = logicvc_layer_state(drm_plane->state);
+   layer_state = devm_kzalloc(dev, sizeof(*layer_state), GFP_KERNEL);
+   if (!layer_state)
+   return NULL;
+
+   layer_state->colorkey_enabled = layer_state_current->colorkey_enabled;
+   layer_state->colorkey_value = layer_state_current->colorkey_value;
+
+   __drm_atomic_helper_plane_duplicate_state(drm_plane,
+ 
_state->drm_plane_state);
+
+   return _state->drm_plane_state;
+}
+
+static void logicvc_plane_destroy_state(struct drm_plane *drm_plane,
+   struct drm_plane_state *state)
+{
+   struct logicvc_drm *logicvc = logicvc_drm(drm_plane->dev);
+   struct device *dev = logicvc->drm_dev.dev;
+   struct logicvc_layer_state *layer_state =

[PATCH v8 1/4] dt-bindings: display: Document the Xylon LogiCVC display controller

2020-12-23 Thread Paul Kocialkowski
The Xylon LogiCVC is a display controller implemented as programmable
logic in Xilinx FPGAs.

Signed-off-by: Paul Kocialkowski 
Acked-by: Rob Herring 
---
 .../display/xylon,logicvc-display.yaml| 313 ++
 1 file changed, 313 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml

diff --git 
a/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml 
b/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml
new file mode 100644
index ..aca78334ad2c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml
@@ -0,0 +1,313 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 Bootlin
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/xylon,logicvc-display.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Xylon LogiCVC display controller
+
+maintainers:
+  - Paul Kocialkowski 
+
+description: |
+  The Xylon LogiCVC is a display controller that supports multiple layers.
+  It is usually implemented as programmable logic and was optimized for use
+  with Xilinx Zynq-7000 SoCs and Xilinx FPGAs.
+
+  Because the controller is intended for use in a FPGA, most of the
+  configuration of the controller takes place at logic configuration bitstream
+  synthesis time. As a result, many of the device-tree bindings are meant to
+  reflect the synthesis configuration and must not be configured differently.
+  Matching synthesis parameters are provided when applicable.
+
+  Layers are declared in the "layers" sub-node and have dedicated 
configuration.
+  In version 3 of the controller, each layer has fixed memory offset and 
address
+  starting from the video memory base address for its framebuffer. In version 
4,
+  framebuffers are configured with a direct memory address instead.
+
+properties:
+  compatible:
+enum:
+  - xylon,logicvc-3.02.a-display
+  - xylon,logicvc-4.01.a-display
+
+  reg:
+maxItems: 1
+
+  clocks:
+minItems: 1
+maxItems: 4
+
+  clock-names:
+minItems: 1
+maxItems: 4
+items:
+  # vclk is required and must be provided as first item.
+  - const: vclk
+  # Other clocks are optional and can be provided in any order.
+  - enum:
+  - vclk2
+  - lvdsclk
+  - lvdsclkn
+  - enum:
+  - vclk2
+  - lvdsclk
+  - lvdsclkn
+  - enum:
+  - vclk2
+  - lvdsclk
+  - lvdsclkn
+
+  interrupts:
+maxItems: 1
+
+  memory-region:
+maxItems: 1
+
+  xylon,display-interface:
+enum:
+  # Parallel RGB interface (C_DISPLAY_INTERFACE == 0)
+  - parallel-rgb
+  # ITU-T BR656 interface (C_DISPLAY_INTERFACE == 1)
+  - bt656
+  # 4-bit LVDS interface (C_DISPLAY_INTERFACE == 2)
+  - lvds-4bits
+  # 3-bit LVDS interface (C_DISPLAY_INTERFACE == 4)
+  - lvds-3bits
+  # DVI interface (C_DISPLAY_INTERFACE == 5)
+  - dvi
+description: Display output interface (C_DISPLAY_INTERFACE).
+
+  xylon,display-colorspace:
+enum:
+  # RGB colorspace (C_DISPLAY_COLOR_SPACE == 0)
+  - rgb
+  # YUV 4:2:2 colorspace (C_DISPLAY_COLOR_SPACE == 1)
+  - yuv422
+  # YUV 4:4:4 colorspace (C_DISPLAY_COLOR_SPACE == 2)
+  - yuv444
+description: Display output colorspace (C_DISPLAY_COLOR_SPACE).
+
+  xylon,display-depth:
+$ref: "/schemas/types.yaml#/definitions/uint32"
+description: Display output depth (C_PIXEL_DATA_WIDTH).
+
+  xylon,row-stride:
+$ref: "/schemas/types.yaml#/definitions/uint32"
+description: Fixed number of pixels in a framebuffer row (C_ROW_STRIDE).
+
+  xylon,syscon:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: |
+  Syscon phandle representing the top-level logicvc instance, useful when
+  the parent node is not the top-level logicvc instance.
+
+  xylon,dithering:
+$ref: "/schemas/types.yaml#/definitions/flag"
+description: Dithering module is enabled (C_XCOLOR)
+
+  xylon,background-layer:
+$ref: "/schemas/types.yaml#/definitions/flag"
+description: |
+  The last layer is used to display a black background (C_USE_BACKGROUND).
+  The layer must still be registered.
+
+  xylon,layers-configurable:
+$ref: "/schemas/types.yaml#/definitions/flag"
+description: |
+  Configuration of layers' size, position and offset is enabled
+  (C_USE_SIZE_POSITION).
+
+  layers:
+type: object
+
+properties:
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+patternProperties:
+  "^layer@[0-9]+$":
+type: object
+
+properties:
+  reg:
+maxItems: 1
+
+  xylon,layer-depth:
+$ref: "/schemas/types.yaml#/definitions/uint32"
+description: La

[PATCH v2 1/2] dt-bindings: pwm: allwinner: Add V3s compatible description

2020-12-18 Thread Paul Kocialkowski
Introduce bindings description for the V3s PWM, which is
register-compatible with the A20 PWM.

Signed-off-by: Paul Kocialkowski 
---
 .../devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml   | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml 
b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml
index 7dcab2bf8128..04ff708fdc86 100644
--- a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml
@@ -24,6 +24,9 @@ properties:
   - items:
   - const: allwinner,sun8i-a83t-pwm
   - const: allwinner,sun8i-h3-pwm
+  - items:
+  - const: allwinner,sun8i-v3s-pwm
+  - const: allwinner,sun7i-a20-pwm
   - items:
   - const: allwinner,sun50i-a64-pwm
   - const: allwinner,sun5i-a13-pwm
-- 
2.29.2



[PATCH v2 2/2] ARM: dts: sun8i-v3s: Add PWM controller and pins definitions

2020-12-18 Thread Paul Kocialkowski
This introduces definitions for the PWM controller found in the V3s,
as well as associated pins. This fashion of the controller has two PWM
outputs and is register-compatible with the A20.

Both PWM outputs were tested on a Lichee Pi Zero with a simple
transistor-LED setup.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun8i-v3s.dtsi | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index bff822b9fa01..f02aa988156d 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -404,6 +404,16 @@ spi0_pins: spi0-pins {
pins = "PC0", "PC1", "PC2", "PC3";
function = "spi0";
};
+
+   pwm0_pin: pwm0-pin {
+   pins = "PB4";
+   function = "pwm0";
+   };
+
+   pwm1_pin: pwm1-pin {
+   pins = "PB5";
+   function = "pwm1";
+   };
};
 
timer@1c20c00 {
@@ -422,6 +432,15 @@ wdt0: watchdog@1c20ca0 {
clocks = <>;
};
 
+   pwm: pwm@1c21400 {
+   compatible = "allwinner,sun8i-v3s-pwm",
+"allwinner,sun7i-a20-pwm";
+   reg = <0x01c21400 0xc>;
+   clocks = <>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
lradc: lradc@1c22800 {
compatible = "allwinner,sun4i-a10-lradc-keys";
reg = <0x01c22800 0x400>;
-- 
2.29.2



[PATCH] ARM: dts: sun8i-v3s: Add CSI0 MCLK pin definition

2020-12-18 Thread Paul Kocialkowski
This adds a device-tree definition for the CSI0 MCLK pin,
which can be used for feeding MIPI CSI-2 sensors.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun8i-v3s.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index a9f5795d4e57..bff822b9fa01 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -337,6 +337,12 @@ pio: pinctrl@1c20800 {
interrupt-controller;
#interrupt-cells = <3>;
 
+   /omit-if-no-ref/
+   csi0_mclk_pin: csi0-mclk-pin {
+   pins = "PE20";
+   function = "csi_mipi";
+   };
+
/omit-if-no-ref/
csi1_8bit_pins: csi1-8bit-pins {
pins = "PE0", "PE2", "PE3", "PE8", "PE9",
-- 
2.29.2



[PATCH] ARM: dts: sun8i-v3s: Add PWM controller and pins definitions

2020-12-17 Thread Paul Kocialkowski
This introduces definitions for the PWM controller found in the V3s,
as well as associated pins. This fashion of the controller has two PWM
outputs and is register-compatible with the A20.

Both PWM outputs were tested on a Lichee Pi Zero with a simple
transistor-LED setup.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun8i-v3s.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index a9f5795d4e57..34a4e638c762 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -398,6 +398,16 @@ spi0_pins: spi0-pins {
pins = "PC0", "PC1", "PC2", "PC3";
function = "spi0";
};
+
+   pwm0_pin: pwm0-pin {
+   pins = "PB4";
+   function = "pwm0";
+   };
+
+   pwm1_pin: pwm1-pin {
+   pins = "PB5";
+   function = "pwm1";
+   };
};
 
timer@1c20c00 {
@@ -416,6 +426,14 @@ wdt0: watchdog@1c20ca0 {
clocks = <>;
};
 
+   pwm: pwm@1c21400 {
+   compatible = "allwinner,sun7i-a20-pwm";
+   reg = <0x01c21400 0xc>;
+   clocks = <>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
lradc: lradc@1c22800 {
compatible = "allwinner,sun4i-a10-lradc-keys";
reg = <0x01c22800 0x400>;
-- 
2.29.2



[PATCH v3 10/15] ARM: dts: sun8i: v3s: Add nodes for MIPI CSI-2 support

2020-12-11 Thread Paul Kocialkowski
MIPI CSI-2 is supported on the V3s with an A31-based MIPI CSI-2 bridge
controller. The controller uses a separate D-PHY, which is the same
that is otherwise used for MIPI DSI, but used in Rx mode.

On the V3s, the CSI0 controller is dedicated to MIPI CSI-2 as it does
not have access to any parallel interface pins.

Add all the necessary nodes (CSI0, MIPI CSI-2 bridge and D-PHY) to
support the MIPI CSI-2 interface.

Note that a fwnode graph link is created between CSI0 and MIPI CSI-2
even when no sensor is connected. This will result in a probe failure
for the controller as long as no sensor is connected but this is fine
since no other interface is available.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun8i-v3s.dtsi | 67 
 1 file changed, 67 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 7b2d684aeb97..b7f2bcd25c86 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -530,6 +530,31 @@ spi0: spi@1c68000 {
#size-cells = <0>;
};
 
+   csi0: camera@1cb {
+   compatible = "allwinner,sun8i-v3s-csi";
+   reg = <0x01cb 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_CSI>,
+< CLK_CSI1_SCLK>,
+< CLK_DRAM_CSI>;
+   clock-names = "bus", "mod", "ram";
+   resets = < RST_BUS_CSI>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+
+   csi0_in_mipi_csi2: endpoint {
+   remote-endpoint = 
<_csi2_out_csi0>;
+   };
+   };
+   };
+   };
+
csi1: camera@1cb4000 {
compatible = "allwinner,sun8i-v3s-csi";
reg = <0x01cb4000 0x3000>;
@@ -552,5 +577,47 @@ gic: interrupt-controller@1c81000 {
#interrupt-cells = <3>;
interrupts = ;
};
+
+   mipi_csi2: csi@1cb1000 {
+   compatible = "allwinner,sun8i-v3s-mipi-csi2",
+"allwinner,sun6i-a31-mipi-csi2";
+   reg = <0x01cb1000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_CSI>,
+< CLK_CSI1_SCLK>;
+   clock-names = "bus", "mod";
+   resets = < RST_BUS_CSI>;
+   status = "disabled";
+
+   phys = <>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mipi_csi2_in: port@0 {
+   reg = <0>;
+   };
+
+   mipi_csi2_out: port@1 {
+   reg = <1>;
+
+   mipi_csi2_out_csi0: endpoint {
+   remote-endpoint = 
<_in_mipi_csi2>;
+   };
+   };
+   };
+   };
+
+   dphy: d-phy@1cb2000 {
+   compatible = "allwinner,sun6i-a31-mipi-dphy";
+   reg = <0x01cb2000 0x1000>;
+   clocks = < CLK_BUS_CSI>,
+< CLK_MIPI_CSI>;
+   clock-names = "bus", "mod";
+   resets = < RST_BUS_CSI>;
+   status = "disabled";
+   #phy-cells = <0>;
+   };
};
 };
-- 
2.29.2



[PATCH v3 12/15] dt-bindings: media: Add A83T MIPI CSI-2 bindings documentation

2020-12-11 Thread Paul Kocialkowski
This introduces YAML bindings documentation for the A83T MIPI CSI-2
controller.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Rob Herring 
---
 .../media/allwinner,sun8i-a83t-mipi-csi2.yaml | 147 ++
 1 file changed, 147 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml

diff --git 
a/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml 
b/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml
new file mode 100644
index ..e607fae7d85e
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml
@@ -0,0 +1,147 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/allwinner,sun8i-a83t-mipi-csi2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A83T MIPI CSI-2 Device Tree Bindings
+
+maintainers:
+  - Paul Kocialkowski 
+
+properties:
+  compatible:
+const: allwinner,sun8i-a83t-mipi-csi2
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+items:
+  - description: Bus Clock
+  - description: Module Clock
+  - description: MIPI-specific Clock
+  - description: Misc CSI Clock
+
+  clock-names:
+items:
+  - const: bus
+  - const: mod
+  - const: mipi
+  - const: misc
+
+  resets:
+maxItems: 1
+
+  # See ./video-interfaces.txt for details
+  ports:
+type: object
+
+properties:
+  port@0:
+type: object
+description: Input port, connect to a MIPI CSI-2 sensor
+
+properties:
+  reg:
+const: 0
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+  clock-lanes:
+maxItems: 1
+
+  data-lanes:
+minItems: 1
+maxItems: 4
+
+required:
+  - data-lanes
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
+  port@1:
+type: object
+description: Output port, connect to a CSI controller
+
+properties:
+  reg:
+const: 1
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+required:
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - resets
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+
+mipi_csi2: csi@1cb1000 {
+compatible = "allwinner,sun8i-a83t-mipi-csi2";
+reg = <0x01cb1000 0x1000>;
+interrupts = ;
+clocks = < CLK_BUS_CSI>,
+ < CLK_CSI_SCLK>,
+ < CLK_MIPI_CSI>,
+ < CLK_CSI_MISC>;
+clock-names = "bus", "mod", "mipi", "misc";
+resets = < RST_BUS_CSI>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+mipi_csi2_in: port@0 {
+reg = <0>;
+
+mipi_csi2_in_ov8865: endpoint {
+data-lanes = <1 2 3 4>;
+
+remote-endpoint = <_out_mipi_csi2>;
+};
+};
+
+mipi_csi2_out: port@1 {
+reg = <1>;
+
+mipi_csi2_out_csi: endpoint {
+remote-endpoint = <_in_mipi_csi2>;
+};
+};
+};
+};
+
+...
-- 
2.29.2



[PATCH v3 11/15] MAINTAINERS: Add entry for the Allwinner A31 MIPI CSI-2 bridge

2020-12-11 Thread Paul Kocialkowski
Add myself as maintainer of the A31 MIPI CSI-2 bridge media driver.

Signed-off-by: Paul Kocialkowski 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0644128640fb..a1352171778b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -709,6 +709,14 @@ T: git git://linuxtv.org/media_tree.git
 F: Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml
 F: drivers/media/platform/sunxi/sun4i-csi/
 
+ALLWINNER A31 MIPI CSI-2 BRIDGE
+M: Paul Kocialkowski 
+L: linux-me...@vger.kernel.org
+S: Maintained
+T: git git://linuxtv.org/media_tree.git
+F: 
Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
+F: drivers/media/platform/sunxi/sun6i-mipi-csi2/
+
 ALLWINNER CPUFREQ DRIVER
 M: Yangtao Li 
 L: linux...@vger.kernel.org
-- 
2.29.2



[PATCH v3 14/15] ARM: dts: sun8i: a83t: Add MIPI CSI-2 controller node

2020-12-11 Thread Paul Kocialkowski
MIPI CSI-2 is supported on the A83T with a dedicated controller that
covers both the protocol and D-PHY. It can be connected to the CSI
interface as a V4L2 subdev through the fwnode graph.

This is not done by default since connecting the bridge without a
subdev attached to it will cause a failure on the CSI driver.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index c010b27fdb6a..d6d55c12b995 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -1066,6 +1066,32 @@ csi_in: port {
};
};
 
+   mipi_csi2: csi@1cb1000 {
+   compatible = "allwinner,sun8i-a83t-mipi-csi2";
+   reg = <0x01cb1000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_CSI>,
+< CLK_CSI_SCLK>,
+< CLK_MIPI_CSI>,
+< CLK_CSI_MISC>;
+   clock-names = "bus", "mod", "mipi", "misc";
+   resets = < RST_BUS_CSI>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mipi_csi2_in: port@0 {
+   reg = <0>;
+   };
+
+   mipi_csi2_out: port@1 {
+   reg = <1>;
+   };
+   };
+   };
+
hdmi: hdmi@1ee {
compatible = "allwinner,sun8i-a83t-dw-hdmi";
reg = <0x01ee 0x1>;
-- 
2.29.2



[PATCH v3 13/15] media: sunxi: Add support for the A83T MIPI CSI-2 controller

2020-12-11 Thread Paul Kocialkowski
The A83T supports MIPI CSI-2 with a composite controller, covering
both the protocol logic and the D-PHY implementation. This controller
seems to be found on the A83T only and probably was abandoned since.

This implementation splits the protocol and D-PHY registers and
uses the PHY framework internally. The D-PHY is not registered as a
standalone PHY driver since it cannot be used with any other
controller.

There are a few notable points about the controller:
- The initialisation sequence involes writing specific magic init
  values that do not seem to make any particular sense given the
  concerned register fields;
- Interrupts appear to be hitting regardless of the interrupt mask
  registers, which can cause a serious flood when transmission errors
  occur.

Only 8-bit and 10-bit Bayer formats are currently supported.
While up to 4 internal channels to the CSI controller exist, only one
is currently supported by this implementation.

This work is based on the first version of the driver submitted by
Kévin L'hôpital, which was adapted to mainline from the Allwinner BSP.
This version integrates MIPI CSI-2 support as a standalone V4L2 subdev
instead of merging it in the sun6i-csi driver.

It was tested on a Banana Pi M3 board with an OV8865 sensor in a 4-lane
configuration.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts  |   2 +-
 drivers/media/platform/sunxi/Kconfig  |   1 +
 drivers/media/platform/sunxi/Makefile |   1 +
 .../sunxi/sun8i-a83t-mipi-csi2/Kconfig|  11 +
 .../sunxi/sun8i-a83t-mipi-csi2/Makefile   |   4 +
 .../sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.c|  92 +++
 .../sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.h|  39 ++
 .../sun8i_a83t_mipi_csi2.c| 657 ++
 .../sun8i_a83t_mipi_csi2.h| 197 ++
 9 files changed, 1003 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Kconfig
 create mode 100644 drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Makefile
 create mode 100644 
drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.c
 create mode 100644 
drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.h
 create mode 100644 
drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_mipi_csi2.c
 create mode 100644 
drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_mipi_csi2.h

diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts 
b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index b437eaeb91e9..bebe843a069b 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -151,7 +151,7 @@ port@1 {
 
csi_in_mipi_csi2: endpoint {
remote-endpoint = <_csi2_out_csi>;
-   }
+   };
};
};
 };
diff --git a/drivers/media/platform/sunxi/Kconfig 
b/drivers/media/platform/sunxi/Kconfig
index 9684e07454ad..db4c07be7e4c 100644
--- a/drivers/media/platform/sunxi/Kconfig
+++ b/drivers/media/platform/sunxi/Kconfig
@@ -3,3 +3,4 @@
 source "drivers/media/platform/sunxi/sun4i-csi/Kconfig"
 source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
 source "drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig"
+source "drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Kconfig"
diff --git a/drivers/media/platform/sunxi/Makefile 
b/drivers/media/platform/sunxi/Makefile
index 887a7cae8fca..9aa01cb01883 100644
--- a/drivers/media/platform/sunxi/Makefile
+++ b/drivers/media/platform/sunxi/Makefile
@@ -3,5 +3,6 @@
 obj-y  += sun4i-csi/
 obj-y  += sun6i-csi/
 obj-y  += sun6i-mipi-csi2/
+obj-y  += sun8i-a83t-mipi-csi2/
 obj-y  += sun8i-di/
 obj-y  += sun8i-rotate/
diff --git a/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Kconfig 
b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Kconfig
new file mode 100644
index ..60e7a9c41065
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Kconfig
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config VIDEO_SUN8I_A83T_MIPI_CSI2
+   tristate "Allwinner A83T MIPI CSI-2 Controller and D-PHY Driver"
+   depends on ARCH_SUNXI || COMPILE_TEST
+   depends on PM && COMMON_CLK && VIDEO_V4L2
+   select REGMAP_MMIO
+   select MEDIA_CONTROLLER
+   select VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+   help
+  Support for the Allwinner A83T MIPI CSI-2 Controller and D-PHY.
diff --git a/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Makefile 
b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Makefile
new file mode 100644
index ..1427d15a879a
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-only
+s

[PATCH v3 15/15] MAINTAINERS: Add entry for the Allwinner A83T MIPI CSI-2 bridge

2020-12-11 Thread Paul Kocialkowski
Add myself as maintainer of the A83T MIPI CSI-2 bridge media driver.

Signed-off-by: Paul Kocialkowski 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index a1352171778b..3b48612657b6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -717,6 +717,14 @@ T: git git://linuxtv.org/media_tree.git
 F: 
Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
 F: drivers/media/platform/sunxi/sun6i-mipi-csi2/
 
+ALLWINNER A83T MIPI CSI-2 BRIDGE
+M: Paul Kocialkowski 
+L: linux-me...@vger.kernel.org
+S: Maintained
+T: git git://linuxtv.org/media_tree.git
+F: 
Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml
+F: drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/
+
 ALLWINNER CPUFREQ DRIVER
 M: Yangtao Li 
 L: linux...@vger.kernel.org
-- 
2.29.2



[PATCH v3 09/15] media: sunxi: Add support for the A31 MIPI CSI-2 controller

2020-12-11 Thread Paul Kocialkowski
The A31 MIPI CSI-2 controller is a dedicated MIPI CSI-2 bridge
found on Allwinner SoCs such as the A31 and V3/V3s.

It is a standalone block, connected to the CSI controller on one side
and to the MIPI D-PHY block on the other. It has a dedicated address
space, interrupt line and clock.

It is represented as a V4L2 subdev to the CSI controller and takes a
MIPI CSI-2 sensor as its own subdev, all using the fwnode graph and
media controller API.

Only 8-bit and 10-bit Bayer formats are currently supported.
While up to 4 internal channels to the CSI controller exist, only one
is currently supported by this implementation.

Signed-off-by: Paul Kocialkowski 
---
 drivers/media/platform/sunxi/Kconfig  |   1 +
 drivers/media/platform/sunxi/Makefile |   1 +
 .../platform/sunxi/sun6i-mipi-csi2/Kconfig|  12 +
 .../platform/sunxi/sun6i-mipi-csi2/Makefile   |   4 +
 .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c   | 590 ++
 .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h   | 117 
 6 files changed, 725 insertions(+)
 create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
 create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
 create mode 100644 
drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
 create mode 100644 
drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h

diff --git a/drivers/media/platform/sunxi/Kconfig 
b/drivers/media/platform/sunxi/Kconfig
index 7151cc249afa..9684e07454ad 100644
--- a/drivers/media/platform/sunxi/Kconfig
+++ b/drivers/media/platform/sunxi/Kconfig
@@ -2,3 +2,4 @@
 
 source "drivers/media/platform/sunxi/sun4i-csi/Kconfig"
 source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
+source "drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig"
diff --git a/drivers/media/platform/sunxi/Makefile 
b/drivers/media/platform/sunxi/Makefile
index fc537c9f5ca9..887a7cae8fca 100644
--- a/drivers/media/platform/sunxi/Makefile
+++ b/drivers/media/platform/sunxi/Makefile
@@ -2,5 +2,6 @@
 
 obj-y  += sun4i-csi/
 obj-y  += sun6i-csi/
+obj-y  += sun6i-mipi-csi2/
 obj-y  += sun8i-di/
 obj-y  += sun8i-rotate/
diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig 
b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
new file mode 100644
index ..47f1bb0779a8
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config VIDEO_SUN6I_MIPI_CSI2
+   tristate "Allwinner A31 MIPI CSI-2 Controller Driver"
+   depends on ARCH_SUNXI || COMPILE_TEST
+   depends on PM && COMMON_CLK && VIDEO_V4L2
+   select REGMAP_MMIO
+   select PHY_SUN6I_MIPI_DPHY
+   select MEDIA_CONTROLLER
+   select VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+   help
+  Support for the Allwinner A31 MIPI CSI-2 Controller.
diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile 
b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
new file mode 100644
index ..14e4e03818b5
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-only
+sun6i-mipi-csi2-y += sun6i_mipi_csi2.o
+
+obj-$(CONFIG_VIDEO_SUN6I_MIPI_CSI2) += sun6i-mipi-csi2.o
diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c 
b/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
new file mode 100644
index ..87307beda4cf
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
@@ -0,0 +1,590 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 Bootlin
+ * Author: Paul Kocialkowski 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sun6i_mipi_csi2.h"
+
+#define MODULE_NAME"sun6i-mipi-csi2"
+
+static const u32 sun6i_mipi_csi2_mbus_codes[] = {
+   MEDIA_BUS_FMT_SBGGR8_1X8,
+   MEDIA_BUS_FMT_SGBRG8_1X8,
+   MEDIA_BUS_FMT_SGRBG8_1X8,
+   MEDIA_BUS_FMT_SRGGB8_1X8,
+   MEDIA_BUS_FMT_SBGGR10_1X10,
+   MEDIA_BUS_FMT_SGBRG10_1X10,
+   MEDIA_BUS_FMT_SGRBG10_1X10,
+   MEDIA_BUS_FMT_SRGGB10_1X10,
+};
+
+/* Video */
+
+static int sun6i_mipi_csi2_s_stream(struct v4l2_subdev *subdev, int on)
+{
+   struct sun6i_mipi_csi2_video *video =
+   sun6i_mipi_csi2_subdev_video(subdev);
+   struct sun6i_mipi_csi2_dev *cdev = sun6i_mipi_csi2_video_dev(video);
+   struct v4l2_subdev *remote_subdev = video->remote_subdev;
+   struct v4l2_fwnode_bus_mipi_csi2 *bus_mipi_csi2 =
+   >endpoint.bus.mipi_csi2;
+   union phy_configure_opts dphy_opts = { 0 };
+   struct phy_configure_opts_mipi_dphy *dphy_cfg = _opts.mipi_dphy;
+   struct regmap *regmap = cdev->regmap;
+   struct v4l2_ctrl *ct

[PATCH v3 06/15] dt-bindings: media: sun6i-a31-csi: Add MIPI CSI-2 input port

2020-12-11 Thread Paul Kocialkowski
The A31 CSI controller supports two distinct input interfaces:
parallel and an external MIPI CSI-2 bridge. The parallel interface
is often connected to a set of hardware pins while the MIPI CSI-2
bridge is an internal FIFO-ish link. As a result, these two inputs
are distinguished as two different ports.

Note that only one of the two may be present on a controller instance.
For example, the V3s has one controller dedicated to MIPI-CSI2 and one
dedicated to parallel.

Update the binding with an explicit ports node that holds two distinct
port nodes: one for parallel input and one for MIPI CSI-2.

This is backward-compatible with the single-port approach that was
previously taken for representing the parallel interface port, which
stays enumerated as fwnode port 0.

Note that additional ports may be added in the future, especially to
support feeding the CSI controller's output to the ISP.

Signed-off-by: Paul Kocialkowski 
---
 .../media/allwinner,sun6i-a31-csi.yaml| 88 ---
 1 file changed, 75 insertions(+), 13 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml 
b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
index 1fd9b5532a21..77ded77505e9 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
@@ -67,6 +67,62 @@ properties:
 
 additionalProperties: false
 
+  ports:
+type: object
+
+properties:
+  port@0:
+type: object
+description: Parallel input port, connect to a parallel sensor
+
+properties:
+  reg:
+const: 0
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+  bus-width:
+enum: [ 8, 10, 12, 16 ]
+
+  pclk-sample: true
+  hsync-active: true
+  vsync-active: true
+
+required:
+  - bus-width
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
+  port@1:
+type: object
+description: MIPI CSI-2 bridge input port
+
+properties:
+  reg:
+const: 1
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+required:
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
 required:
   - compatible
   - reg
@@ -95,19 +151,25 @@ examples:
   "ram";
 resets = < RST_BUS_CSI>;
 
-port {
-/* Parallel bus endpoint */
-csi1_ep: endpoint {
-remote-endpoint = <_ep>;
-bus-width = <16>;
-
-/*
- * If hsync-active/vsync-active are missing,
- * embedded BT.656 sync is used.
- */
- hsync-active = <0>; /* Active low */
- vsync-active = <0>; /* Active low */
- pclk-sample = <1>;  /* Rising */
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+/* Parallel bus endpoint */
+csi1_ep: endpoint {
+remote-endpoint = <_ep>;
+bus-width = <16>;
+
+/*
+ * If hsync-active/vsync-active are missing,
+ * embedded BT.656 sync is used.
+ */
+ hsync-active = <0>; /* Active low */
+ vsync-active = <0>; /* Active low */
+ pclk-sample = <1>;  /* Rising */
+};
 };
 };
 };
-- 
2.29.2



  1   2   3   4   5   6   7   8   9   10   >