On Fri, Jan 18, 2019 at 11:18 PM Andre Przywara wrote:
>
> On Fri, 18 Jan 2019 22:11:36 +0530
> Jagan Teki wrote:
>
> Hi,
>
> > On Fri, Jan 18, 2019 at 6:00 PM Andre Przywara
> > wrote:
> > >
> > > On Fri, 18 Jan 2019 07:17:41 -0500
> > > Tom Rini wrote:
> > >
> > > > On Fri, Jan 18, 2019 at
From: Jagan Teki
>From our driver's perspective there is no difference between the MMC
controllers for the A83T, A64 and H5 compared to the A10/A20 type.
As we now have support for the formerly missing reset gates, we can
add their compatible strings, to make those SoCs work with DM_MMC.
Even though the H6 MMC device is fully compatible to the A64
implementation, we need to differentiate between the two, as the mod
clock is on a different address, and we don't use the DT for that yet.
Add a separate "variant" which just holds the different MMIO address.
Signed-off-by: Andre
Now that we have the gate clocks and the reset gates in our new
Allwinner clock driver, let's make use of them in the MMC driver, when
DM_MMC is defined.
We treat the reset device as optional now, as the older SoCs don't
implement it.
Signed-off-by: Andre Przywara
---
drivers/mmc/sunxi_mmc.c |
From: Jagan Teki
Enable DM_MMC for all Allwinner SoCs, this will eventually
enable BLK.
Also removed DM_MMC enablement in few parts of sunxi
configurations.
Signed-off-by: Jagan Teki
Signed-off-by: Andre Przywara
---
arch/arm/Kconfig | 1 +
arch/arm/mach-sunxi/Kconfig
If a board DT describes a cd-gpios property, but also marks the storage
as non-removable, we must ignore the GPIO (as Linux does).
Teach the DM_MMC part of the Allwinner MMC driver about the
non-removable DT property, to fix DM_MMC access on the SoPine and
Pine64-LTS board.
Signed-off-by: Andre
Add the Allwinner A80 mod clock address and bind it to its compatible
string. The special config clock is handled via the clock driver.
Signed-off-by: Andre Przywara
---
drivers/mmc/sunxi_mmc.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/mmc/sunxi_mmc.c
The A80 handles resets and clock gates for the MMC devices differently,
outside of the CCU IP block. Consequently we have a separate clock
device with a separate binding for that.
Implement that with the respective clock gates and resets to allow the
A80 taking part in the DM_MMC game.
The Allwinner MMC supports both the legacy approach and the driver model,
at the cost of quite some #ifdefs.
Mark the closing #endifs with their respective config symbol, to make it
more obvious where each part ends and begins.
Signed-off-by: Andre Przywara
---
drivers/mmc/sunxi_mmc.c | 6
This series enables the Allwinner MMC driver to drive all SoCs with its
DM_MMC variant. We use the gates clock and reset support from the new
clock driver, but keep the actual mod clock in its somewhat hackish
state. Properly supporting this via the clock driver is a bit more work.
The
Add the MMC clock gates and reset bits for all the Allwinner SoCs.
This allows them to be used by the MMC driver.
We don't advertise the mod clock yet, as this is still handled by the
MMC driver.
Signed-off-by: Andre Przywara
---
drivers/clk/sunxi/clk_a10.c | 4
Dne četrtek, 17. januar 2019 ob 08:24:02 CET je Priit Laes napisal(a):
> On Wed, Jan 16, 2019 at 06:00:32PM +0100, Jernej Škrabec wrote:
> > Dne sreda, 16. januar 2019 ob 13:09:58 CET je Priit Laes napisal(a):
> > > On Thu, Jan 10, 2019 at 06:10:59PM +0100, Jernej Škrabec wrote:
> > > > Dne
On Fri, Jan 18, 2019 at 03:57:30PM +0100, Paul Kocialkowski wrote:
> This adds nodes for the Video Engine and the associated reserved memory
> for the A10. Up to 96 MiB of memory are dedicated to the CMA pool.
>
> The VPU can only map the first 256 MiB of DRAM, so the reserved memory
> pool has
On Fri, Jan 18, 2019 at 03:51:10PM +0100, Paul Kocialkowski wrote:
> This series implements support for YUV formats using the display engine
> frontend in the sun4i DRM driver, with various fixes along the way.
> Scaling is supported for every format handled by the frontend.
>
> The tiling mode
On Fri, 18 Jan 2019 22:11:36 +0530
Jagan Teki wrote:
Hi,
> On Fri, Jan 18, 2019 at 6:00 PM Andre Przywara
> wrote:
> >
> > On Fri, 18 Jan 2019 07:17:41 -0500
> > Tom Rini wrote:
> >
> > > On Fri, Jan 18, 2019 at 11:53:49AM +, Andre Przywara wrote:
> > > > On Thu, 17 Jan 2019 22:39:44
On Fri, Jan 11, 2019 at 4:48 PM Jagan Teki wrote:
>
> CLK and DM_RESET drivers are now available for all of
> the Allwinner platforms, so enable them in arch/arm/Kconfig
>
> Enabling CLK will select DM_RESET by default.
>
> Signed-off-by: Jagan Teki
> ---
Applied to u-boot-sunxi/master
--
You
On Fri, Jan 11, 2019 at 12:13 AM Jagan Teki wrote:
>
> This series fixes few comments from previous verision for Allwinner
> clock gates, resets and dropped clock tree patches which I have
> mentioned on previous series[1].
>
> Changes for v6:
> - use ARRAY_SIZE for reset array instead of number
On Fri, Jan 11, 2019 at 4:46 PM Jagan Teki wrote:
>
> Update all A80 devicetree dtsi and dtsi files from
> Linux-v4.18-rc3 with below commits.
>
> arch/arm/boot/dts/sun9i-a80*:
>
> commit 190e3138f9577885691540dca59c2f07540bde04
> Merge: cafc87023b0d a7affb13b271
> Author: Arnd Bergmann
> Date:
On Fri, Jan 18, 2019 at 6:00 PM Andre Przywara wrote:
>
> On Fri, 18 Jan 2019 07:17:41 -0500
> Tom Rini wrote:
>
> > On Fri, Jan 18, 2019 at 11:53:49AM +, Andre Przywara wrote:
> > > On Thu, 17 Jan 2019 22:39:44 +0530
> > > Jagan Teki wrote:
> > >
> > > > V2 for previous version[1] changes,
Add dts node details for Allwinner A64 CSI controller.
A64 CSI has similar features as like in H3, but the CSI_SCLK
need to update it to 300MHz than default clock rate.
Signed-off-by: Jagan Teki
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 20 +++
1 file changed, 20
CSI block in Allwinner A64 has similar features as like in H3,
but default mod clock rate in BSP along with latest mainline testing
require to operate it at 300MHz.
So, add A64 CSI compatibe along with mod_rate quirk.
Signed-off-by: Jagan Teki
---
Unfortunately default CSI_SCLK rate cannot work properly to
drive the connected sensor interface, particularly on few
Allwinner SoC's like A64.
So, add mod_rate quirk via driver data so-that the respective
SoC's which require to alter the default mod clock rate can assign
the operating clock
This is v6 set for previous version[1] series to support CSI on Allwinner A64.
Tested 640x480, 320x240, 720p, 1080p resolutions UYVY8_2X8 format.
Changes for v6:
- set the mod rate in seett_power instead of probe
Changes for v5:
- Add mod_rate quirk for better handling clk_set code
Changes for
On Thu, Jan 17, 2019 at 10:02 AM Jagan Teki wrote:
>
> On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard
> wrote:
> >
> > On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote:
> > > > > > > > Again, I cannot help you without the datasheet for the panels
> > > > > > > > you're
> > > > > > > >
This adds nodes for the Video Engine and the associated reserved memory
for the A10. Up to 96 MiB of memory are dedicated to the CMA pool.
The VPU can only map the first 256 MiB of DRAM, so the reserved memory
pool has to be located in that area. Following Allwinner's decision in
downstream
This adds support for the C1 SRAM region (to be used with the SRAM
controller driver) for the A10 platform. The region is shared
between the Video Engine and the CPU.
Signed-off-by: Paul Kocialkowski
---
arch/arm/boot/dts/sun4i-a10.dtsi | 13 +
1 file changed, 13 insertions(+)
diff
From: Maxime Ripard
The COEF_RDY bit is used to tell the hardware that new FIR filters
coefficients have been written to the registers and that the hardware
should take them into account starting next frame.
Signed-off-by: Maxime Ripard
Signed-off-by: Paul Kocialkowski
---
From: Maxime Ripard
The COEF_RDY bit isn't found in all the SoCs featuring some variant of the
frontend.
Add it to our quirks structure.
Signed-off-by: Maxime Ripard
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 9 +
This adds the appropriate device-tree compatible and quirk data for
hooking frontend support for the A20. It supports the FIR coefficients
ready bit but not the access control bit. It also takes different phase
values than the A33 for these coefficients.
The compatible is already used in the A10
From: Maxime Ripard
The FIR filters phase depend on the SoC, so let's move it to our quirks
structure instead of removing them.
Signed-off-by: Maxime Ripard
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 28 --
This adds the appropriate device-tree compatible for hooking frontend
support for the A20. Since the hardware is very similar to the A10, it
shares the same quirks (which were already introduced).
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 4
1 file
From: Maxime Ripard
The ACCESS_CTRL bit is not found on all the variants of the frontend, so
let's introduce a structure that will hold whether or not we need to set
it, and associate it with the compatible.
This will be extended for further similar quirks later on.
Signed-off-by: Maxime
On Fri, Jan 18, 2019 at 03:04:18PM +0100, Maxime Ripard wrote:
> On Fri, Jan 18, 2019 at 10:10:53AM +, Priit Laes wrote:
> > > > > > > It doesn't look related to the clock rate itself, since it doesn't
> > > > > > > change between the two cases. However, in one case the DDC clock
> > > > > >
This is the final step to indicate to the core that our driver
supports framebuffer modifiers.
Signed-off-by: Paul Kocialkowski
Acked-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
This introduces a list of supported modifiers for the driver, that
includes the Allwinner tiled modifier, as well as a format_mod_supported
callback.
The callback uses both the backend and frontend helpers to indicate
per-format modifier support (including for the linear modifier).
This introduces a helper to check whether a frontend input format
supports tiling mode. This helper is used when tiling is requested in
the frontend format support helper.
Only semiplanar and planar YUV formats are supported by the hardware.
Signed-off-by: Paul Kocialkowski
Acked-by: Maxime
This introduces the data input mode definitions for the tiled YUV mode,
that are used in the input mode helper if tiling is requested.
The modifier is passed to the helper from the framebuffer to determine
if tiling is requested.
Only semiplanar and planar YUV formats are supported for tiling
Display engine drivers often need to distinguish between different types of
YUV sub-sampling. This introduces helpers to check for common sub-sampling
ratios in their commonly-used denomination from the DRM format info.
Signed-off-by: Paul Kocialkowski
Reviewed-by: Maxime Ripard
---
This introduces stride and offset configuration for the VPU tiling mode.
Stride is calculated differently than it is for linear formats and an
offset is calculated, for which new register definitions are introduced.
Signed-off-by: Paul Kocialkowski
Acked-by: Maxime Ripard
---
In prevision of adding support for YUV formats, set the YUV to RGB
colorspace conversion coefficients if required and don't bypass the
CSC engine when converting.
The BT601 coefficients from the A33 BSP are copied over from the backend
code. Because of module inter-dependency, we can't have the
Both the backend and the frontend need the BT.601 CSC coefficients for
YUV to RGB conversion. Since the backend has a dependency on the
frontend (and not the other way round), move the coefficients there
so that both can access them without having to duplicate them.
Signed-off-by: Paul
It is often useful to check whether the DRM format info retrieved from
the DRM framebuffer matches a specific YUV planes disposition.
This introduces helpers to quickly check that a provided format info
matches a YUV format with a specific disposition, in commonly-used
terminology.
The intent of
This introduces specific definitions for vendor Allwinner and its
associated tiled format modifier. This modifier is used for the output
format of the VPU, that can be imported directly with the display
engine hardware supported by the sun4i-drm driver.
Signed-off-by: Paul Kocialkowski
Checking for the number of planes is not sufficient to en ensure that
the format is a packed YUV422.
Use explicit fourcc helpers for the check instead.
Signed-off-by: Paul Kocialkowski
Acked-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 3 ++-
1 file changed, 2 insertions(+),
This introduces support for packed YUV formats with 4:2:2 sampling using
the frontend. Definitions are introduced for the data format and pixel
sequence input format register values.
Signed-off-by: Paul Kocialkowski
Acked-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 22
The helper returning the input mode needs to know the number of planes
for the provided format. Passing the fourcc requires iterating through
the format info list in order to return the number of planes.
Pass the DRM format info structure directly instead to all helpers
related to configuring the
This series implements support for YUV formats using the display engine
frontend in the sun4i DRM driver, with various fixes along the way.
Scaling is supported for every format handled by the frontend.
The tiling mode used by the VPU on Allwinner platforms is also supported
by this series and a
Since all the RGB input formats have the same value for the DATA_FMT
field of the INPUT_FMT register, we can group them when the format is
known to be RGB. Here, we assume that a non-YUV format is RGB, because
the hardware does not support any other colorspace than RGB and YUV.
Use the DRM format
Planar YUV formats come with 3 distinct planes, which requires
configuring the frontend line stride and address registers for the
third plane.
Our hardware only supports the YUV planes order and in order to support
formats with a YVU plane order, a helper is introduced to indicate
whether to
Semi-planar YUV formats use two distinct planes, one for luminance and
one for chrominance. To add support for them, we need to configure the
second line stride and buffer address registers to setup the second YUV
plane.
New definitions are introduced to configure the input format register
for
From: Maxime Ripard
Unlike what is currently being done, the ACCESS_CTRL bit documentation asks
that this bit should be set before modifying any register. The code in the
BSP also does this, so make sure we do this as well.
Signed-off-by: Maxime Ripard
Signed-off-by: Paul Kocialkowski
---
Semi-planar YUV formats use two distinct planes, one for luminance and
one for chrominance. To add support for them, we need to configure the
second line stride and buffer address registers to setup the second YUV
plane.
New definitions are introduced to configure the input format register
for
This adds the appropriate device-tree compatible and quirk data for
hooking frontend support for the A20. It supports the FIR coefficients
ready bit but not the access control bit. It also takes different phase
values than the A33 for these coefficients.
The compatible is already used in the A10
From: Maxime Ripard
The COEF_RDY bit isn't found in all the SoCs featuring some variant of the
frontend.
Add it to our quirks structure.
Signed-off-by: Maxime Ripard
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 9 +
In prevision of adding support for YUV formats, set the YUV to RGB
colorspace conversion coefficients if required and don't bypass the
CSC engine when converting.
The BT601 coefficients from the A33 BSP are copied over from the backend
code. Because of module inter-dependency, we can't have the
This introduces a helper to check whether a frontend input format
supports tiling mode. This helper is used when tiling is requested in
the frontend format support helper.
Only semiplanar and planar YUV formats are supported by the hardware.
Signed-off-by: Paul Kocialkowski
Acked-by: Maxime
This introduces a list of supported modifiers for the driver, that
includes the Allwinner tiled modifier, as well as a format_mod_supported
callback.
The callback uses both the backend and frontend helpers to indicate
per-format modifier support (including for the linear modifier).
This introduces support for packed YUV formats with 4:2:2 sampling using
the frontend. Definitions are introduced for the data format and pixel
sequence input format register values.
Signed-off-by: Paul Kocialkowski
Acked-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 22
The helper returning the input mode needs to know the number of planes
for the provided format. Passing the fourcc requires iterating through
the format info list in order to return the number of planes.
Pass the DRM format info structure directly instead to all helpers
related to configuring the
From: Maxime Ripard
The COEF_RDY bit is used to tell the hardware that new FIR filters
coefficients have been written to the registers and that the hardware
should take them into account starting next frame.
Signed-off-by: Maxime Ripard
Signed-off-by: Paul Kocialkowski
---
From: Maxime Ripard
The FIR filters phase depend on the SoC, so let's move it to our quirks
structure instead of removing them.
Signed-off-by: Maxime Ripard
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 28 --
Checking for the number of planes is not sufficient to en ensure that
the format is a packed YUV422.
Use explicit fourcc helpers for the check instead.
Signed-off-by: Paul Kocialkowski
Acked-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 3 ++-
1 file changed, 2 insertions(+),
This adds the appropriate device-tree compatible for hooking frontend
support for the A20. Since the hardware is very similar to the A10, it
shares the same quirks (which were already introduced).
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 4
1 file
This introduces stride and offset configuration for the VPU tiling mode.
Stride is calculated differently than it is for linear formats and an
offset is calculated, for which new register definitions are introduced.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/sun4i/sun4i_frontend.c |
This introduces specific definitions for vendor Allwinner and its
associated tiled format modifier. This modifier is used for the output
format of the VPU, that can be imported directly with the display
engine hardware supported by the sun4i-drm driver.
Signed-off-by: Paul Kocialkowski
From: Maxime Ripard
The ACCESS_CTRL bit is not found on all the variants of the frontend, so
let's introduce a structure that will hold whether or not we need to set
it, and associate it with the compatible.
This will be extended for further similar quirks later on.
Signed-off-by: Maxime
This is the final step to indicate to the core that our driver
supports framebuffer modifiers.
Signed-off-by: Paul Kocialkowski
Acked-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
This introduces the data input mode definitions for the tiled YUV mode,
that are used in the input mode helper if tiling is requested.
The modifier is passed to the helper from the framebuffer to determine
if tiling is requested.
Only semiplanar and planar YUV formats are supported for tiling
This series implements support for YUV formats using the display engine
frontend in the sun4i DRM driver, with various fixes along the way.
Scaling is supported for every format handled by the frontend.
The tiling mode used by the VPU on Allwinner platforms is also supported
by this series and a
It is often useful to check whether the DRM format info retrieved from
the DRM framebuffer matches a specific YUV planes disposition.
This introduces helpers to quickly check that a provided format info
matches a YUV format with a specific disposition, in commonly-used
terminology.
The intent of
Planar YUV formats come with 3 distinct planes, which requires
configuring the frontend line stride and address registers for the
third plane.
Our hardware only supports the YUV planes order and in order to support
formats with a YVU plane order, a helper is introduced to indicate
whether to
Since all the RGB input formats have the same value for the DATA_FMT
field of the INPUT_FMT register, we can group them when the format is
known to be RGB. Here, we assume that a non-YUV format is RGB, because
the hardware does not support any other colorspace than RGB and YUV.
Use the DRM format
Display engine drivers often need to distinguish between different types of
YUV sub-sampling. This introduces helpers to check for common sub-sampling
ratios in their commonly-used denomination from the DRM format info.
Signed-off-by: Paul Kocialkowski
Reviewed-by: Maxime Ripard
---
On Fri, Jan 18, 2019 at 10:10:53AM +, Priit Laes wrote:
> > > > > > It doesn't look related to the clock rate itself, since it doesn't
> > > > > > change between the two cases. However, in one case the DDC clock is
> > > > > > enabled and in the other it's disabled.
> > > > > >
> > > > > >
On Fri, 18 Jan 2019 07:17:41 -0500
Tom Rini wrote:
> On Fri, Jan 18, 2019 at 11:53:49AM +, Andre Przywara wrote:
> > On Thu, 17 Jan 2019 22:39:44 +0530
> > Jagan Teki wrote:
> >
> > > V2 for previous version[1] changes, for enabling DM_MMC
> > > on Allwinner platform.
> >
> > So this
On Fri, Jan 18, 2019 at 11:53:49AM +, Andre Przywara wrote:
> On Thu, 17 Jan 2019 22:39:44 +0530
> Jagan Teki wrote:
>
> > V2 for previous version[1] changes, for enabling DM_MMC
> > on Allwinner platform.
>
> So this is a neat and simple solution to the DM_MMC problem, to the
> point where
On Thu, 17 Jan 2019 22:39:44 +0530
Jagan Teki wrote:
> V2 for previous version[1] changes, for enabling DM_MMC
> on Allwinner platform.
So this is a neat and simple solution to the DM_MMC problem, to the
point where I am wondering why we actually need all those DT driven
clock and reset drivers
On Thu, Jan 17, 2019 at 12:33:40PM +0100, Maxime Ripard wrote:
> On Wed, Jan 16, 2019 at 08:35:16PM +, Priit Laes wrote:
> > On Wed, Jan 16, 2019 at 08:24:42PM +0100, Maxime Ripard wrote:
> > > Hi Priit,
> > >
> > > On Wed, Jan 16, 2019 at 07:58:54AM +, Priit Laes wrote:
> > > > > On Mon,
78 matches
Mail list logo
