Dne torek, 27. november 2018 ob 17:30:00 CET je Jernej Škrabec napisal(a):
> Dne torek, 27. november 2018 ob 16:50:28 CET je Maxime Ripard napisal(a):
> > Hi Jernej,
> >
> > Thanks for your review!
> >
> > On Sat, Nov 24, 2018 at 09:43:43PM +0100, Jernej Škrabec wrote:
> > > > +enum
Hi!
Dne četrtek, 15. november 2018 ob 15:56:49 CET je Maxime Ripard napisal(a):
> From: Pawel Osciak
>
> Stateless video codecs will require both the H264 metadata and slices in
> order to be able to decode frames.
>
> This introduces the definitions for a new pixel format for H264 slices that
Dne torek, 27. november 2018 ob 16:50:28 CET je Maxime Ripard napisal(a):
> Hi Jernej,
>
> Thanks for your review!
>
> On Sat, Nov 24, 2018 at 09:43:43PM +0100, Jernej Škrabec wrote:
> > > +enum cedrus_h264_sram_off {
> > > + CEDRUS_SRAM_H264_PRED_WEIGHT_TABLE = 0x000,
> > > +
On Wed, Nov 21, 2018 at 08:05:24PM +0200, Priit Laes wrote:
> This is a resend/v2 of a "Stop AXP from crashing when enabling LDO3" series,
> posted by Olliver Schinagl in March 2017. Unfortunately it never got past
> initial discussion [1], but most Olimex Lime2 boards are still running
> into
Hi Jernej,
Thanks for your review!
On Sat, Nov 24, 2018 at 09:43:43PM +0100, Jernej Škrabec wrote:
> > +enum cedrus_h264_sram_off {
> > + CEDRUS_SRAM_H264_PRED_WEIGHT_TABLE = 0x000,
> > + CEDRUS_SRAM_H264_FRAMEBUFFER_LIST = 0x100,
> > + CEDRUS_SRAM_H264_REF_LIST_0 =
On Tue, Nov 27, 2018 at 3:55 PM Maxime Ripard wrote:
>
> On Tue, Nov 20, 2018 at 09:55:42PM +0530, Jagan Teki wrote:
> > On Tue, Nov 20, 2018 at 9:27 PM Maxime Ripard
> > wrote:
> > >
> > > On Thu, Nov 15, 2018 at 11:19:53PM +0530, Jagan Teki wrote:
> > > > On Thu, Nov 15, 2018 at 3:26 PM
Hello,
On Mon, Nov 26, 2018 at 10:31:58PM +0100, Uwe Kleine-König wrote:
> On Mon, Nov 26, 2018 at 12:23:19AM +0800, Hao Zhang wrote:
> > The sun8i R40/T3/V40 PWM has 8 PWM channals and divides to 4 PWM pairs,
> > each PWM pair built-in 1 clock module, 2 timer logic module and 1
> > programmable
On Tue, Nov 27, 2018 at 09:35:23AM +0100, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Nov 27, 2018 at 08:52:26AM +0100, Maxime Ripard wrote:
> > On Mon, Nov 26, 2018 at 12:18:59AM +0800, Hao Zhang wrote:
> > > + - clocks: From common clock binding, handle to the parent clock.
> > > + -
On Mon, Nov 26, 2018 at 05:37:09PM +0530, Jagan Teki wrote:
> I'm about to send next version by combining with burst mode changes in
> one series. Do you have any further inputs on this. I didn't not see
> any breakage with 4-lane devices, but has issue with 2-lane w/o this change.
I'd rather
On Tue, Nov 20, 2018 at 09:55:42PM +0530, Jagan Teki wrote:
> On Tue, Nov 20, 2018 at 9:27 PM Maxime Ripard
> wrote:
> >
> > On Thu, Nov 15, 2018 at 11:19:53PM +0530, Jagan Teki wrote:
> > > On Thu, Nov 15, 2018 at 3:26 PM Maxime Ripard
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Tue,
On Tue, Nov 20, 2018 at 09:52:23PM +0530, Jagan Teki wrote:
> On Tue, Nov 20, 2018 at 9:15 PM Maxime Ripard
> wrote:
> >
> > On Mon, Nov 19, 2018 at 04:30:37PM +0530, Jagan Teki wrote:
> > > On Mon, Nov 19, 2018 at 2:00 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Fri, Nov 16, 2018 at
On Sun, Nov 25, 2018 at 10:43:19AM +0300, Mesih Kilinc wrote:
> F1C100s is one product with the suniv die, which has a 32MiB co-packaged
> DDR1 DRAM chip. As we have the support for suniv pin controller and CCU now,
> add a
> initial DTSI for it.
>
> Signed-off-by: Mesih Kilinc
> ---
>
65;5402;1c
On Sun, Nov 25, 2018 at 10:43:10AM +0300, Mesih Kilinc wrote:
> This patch adds support for suniv Allwinner ARMv5 F1C100s SoC which has
> stripped version of interrupt controller that found in A10/A13.
>
> Signed-off-by: Mesih Kilinc
Acked-by: Maxime Ripard
Maxime
--
Maxime
On Sun, Nov 25, 2018 at 10:43:09AM +0300, Mesih Kilinc wrote:
> This patch moves IC specific register offsets to sun4i_irq_chip_data
> struct in order to support different chips.
>
> Signed-off-by: Mesih Kilinc
Acked-by: Maxime Ripard
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and
On Sun, Nov 25, 2018 at 10:43:08AM +0300, Mesih Kilinc wrote:
> In order to support different chips, IC specific data should be hold in
> a struct. This patch moves irq_base and irq_domain global variables to
> struct.
>
> Signed-off-by: Mesih Kilinc
Acked-by: Maxime Ripard
Thanks!
Maxime
--
On Fri, Nov 23, 2018 at 10:25:10AM +0100, Paul Kocialkowski wrote:
> 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
On Fri, Nov 23, 2018 at 10:25:06AM +0100, Paul Kocialkowski wrote:
> 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.
>
>
On Fri, Nov 23, 2018 at 10:25:04AM +0100, Paul Kocialkowski wrote:
> To prepare the introduction of tiled mode support, pass the framebuffer
> format modifier to the helpers dealing with format support.
>
> Since only linear mode is supported for now, add corresponding checks in
> each helper.
>
On Fri, Nov 23, 2018 at 10:24:54AM +0100, Paul Kocialkowski wrote:
> This introduces support for the BGRX output format for the frontend,
> with its associated output format value definition.
>
> Signed-off-by: Paul Kocialkowski
Applied, thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded
On Fri, Nov 23, 2018 at 11:30:20AM +, Brian Starkey wrote:
> Hi Paul,
>
> On Fri, Nov 23, 2018 at 10:25:03AM +0100, Paul Kocialkowski wrote:
> >This introduces a dedicated ioctl for allocating buffers for the VPU
> >tiling mode. It allows setting up buffers that comply to the hardware
>
On Fri, Nov 23, 2018 at 10:25:01AM +0100, Paul Kocialkowski wrote:
> Our hardware requires the pitch to be an even number when using YUV
> formats with the frontend. Implement a driver-specific callback for GEM
> dumb allocation that sets the pitch accordingly.
>
> Since only the bpp is passed
On Fri, Nov 23, 2018 at 10:25:02AM +0100, Paul Kocialkowski wrote:
> 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
On Fri, Nov 23, 2018 at 10:24:59AM +0100, Paul Kocialkowski wrote:
> 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.
>
On Fri, Nov 23, 2018 at 10:24:57AM +0100, Paul Kocialkowski wrote:
> The frontend comes with two "channels", that can be configured
> independently. When used in YUV mode, the first channel (CH0) represents
> the luminance component while the second channel (CH1) represents the
> chrominance. In
On Fri, Nov 23, 2018 at 10:24:55AM +0100, Paul Kocialkowski wrote:
> From: Paul Kocialkowski
>
> The values in the BT601 YUV to RGB colorspace translation are not
> simply coded as multiples, but rather as fixed-point signed fractional
> values on a given number of bits. Add an explanation about
On Fri, Nov 23, 2018 at 10:24:53AM +0100, Paul Kocialkowski wrote:
> This introduces support for the BGRX input format for the frontend,
> with its associated pixel sequence value definition. Other fields are
> already configured correctly as they no longer depend on the format's
> fourcc
On Fri, Nov 23, 2018 at 10:24:51AM +0100, Paul Kocialkowski wrote:
> Use the number of planes associated with the DRM format to determine the
> input mode configuration instead of the format iteself. This way, the
> helper can be used for all packed formats without future changes.
>
>
On Fri, Nov 23, 2018 at 10:24:50AM +0100, Paul Kocialkowski wrote:
> This introduces proper definitions for the input and output format
> configuration registers instead of a macro and raw values in the code,
> with the intent to increase code readability and reduce indirections.
>
>
On Fri, Nov 23, 2018 at 10:24:49AM +0100, Paul Kocialkowski wrote:
> This introduces new helpers for retrieving the input data mode and pixel
> sequence register field values based on the DRM format instead of
> hardcoding these. This makes it easier to add support for more formats.
>
>
On Fri, Nov 23, 2018 at 10:24:48AM +0100, Paul Kocialkowski wrote:
> In order to support YUV to RGB conversion with the frontend (which is
> generally used for connecting with the backend), the CSC block must not
> be bypassed.
>
> As a result, the bit to enable CSC bypass is moved from the
On Fri, Nov 23, 2018 at 10:24:47AM +0100, Paul Kocialkowski wrote:
> Since more formats can be supported by the frontend, rename the
> variable listing the layer formats to avoid suggesting that the backend
> itself supports all the listed formats.
>
> Signed-off-by: Paul Kocialkowski
Applied,
On Fri, Nov 23, 2018 at 10:24:46AM +0100, Paul Kocialkowski wrote:
> Our hardware has a limited number of YUV planes (usually 1) that can be
> supported using the backend only. However, YUV planes can also be
> supported by the frontend and must then not be counted when checking for
> that
On Fri, Nov 23, 2018 at 10:24:45AM +0100, Paul Kocialkowski wrote:
> 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
On Fri, Nov 23, 2018 at 10:24:42AM +0100, Paul Kocialkowski wrote:
> This introduces new format helpers that use the previously-introduced
> format info helpers for checking YUV planes disposition.
>
> Only the format fourcc is required by these helpers and the formats are
> iterated from the
On Fri, Nov 23, 2018 at 10:24:43AM +0100, Paul Kocialkowski wrote:
> 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.
>
>
On Fri, Nov 23, 2018 at 10:24:41AM +0100, Paul Kocialkowski wrote:
> 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
On Fri, Nov 23, 2018 at 10:24:40AM +0100, Paul Kocialkowski wrote:
> This adds a new helper to check whether the format described by its
> fourcc code uses a YUV colorspace, by returning the is_yuv entry for
> the DRM info entry matching that format.
>
> Signed-off-by: Paul Kocialkowski
On Fri, Nov 23, 2018 at 10:24:39AM +0100, Paul Kocialkowski wrote:
> Before this patch, it is assumed that a plane is supported either
> through the frontend or through the backend alone. However, the DRM
> interface does not allow finely reporting our hardware capabilities
> and there are cases
On Fri, Nov 23, 2018 at 10:24:38AM +0100, Paul Kocialkowski wrote:
> Checking that scaling is in use is not sufficient as a condition to
> decide to use the frontend.
>
> Since not all layer formats are supported by the frontend, we need to
> check for that support first. Then, the frontend must
On Fri, Nov 23, 2018 at 10:24:36AM +0100, Paul Kocialkowski wrote:
> In order to check whether the backend supports a specific format, an
> explicit list and a related helper are introduced.
>
> The prototype of this helper is added to the header so that it can be
> called from sun4i_layer later
On Fri, Nov 23, 2018 at 10:24:37AM +0100, Paul Kocialkowski wrote:
> In order to check whether the frontend supports a specific format, an
> explicit list and a related helper are introduced.
>
> Just like in the backend, the prototype of the helper is added to the
> frontend header so that it
Hello,
On Tue, Nov 27, 2018 at 08:52:26AM +0100, Maxime Ripard wrote:
> On Mon, Nov 26, 2018 at 12:18:59AM +0800, Hao Zhang wrote:
> > + - clocks: From common clock binding, handle to the parent clock.
> > + - clock-names: Must contain the clock names described just above.
>
> [...]
>
> You
On Fri, Nov 23, 2018 at 10:24:34AM +0100, Paul Kocialkowski wrote:
> The frontend documentation (for the A33) mentions that ARGB is supported
> as output, but with the alpha component always set to 0xff. In practice,
> this means that the alpha component cannot be preserved when going
> through
On Fri, Nov 23, 2018 at 10:24:33AM +0100, Paul Kocialkowski wrote:
> This adds a dedicated function for cleaning the video and YUV source
> channel layer enable bits. This function is called first on layer atomic
> update to make sure that there are no leftover bits from previous
> plane
On Fri, Nov 23, 2018 at 10:24:35AM +0100, Paul Kocialkowski wrote:
> The backend allows integer-only scaling but can handle alpha components,
> unlike the frontend. It could be useful to add support for this
> eventually, so add a short TODO comment describing the situation.
>
> Signed-off-by:
On Mon, Nov 26, 2018 at 01:59:46PM +0800, Chen-Yu Tsai wrote:
> This patch enables audio via the SoC's internal audio codec. All
> relevant device nodes are enabled, and the routing is set to match
> the board design. MIC1 is routed to an onboard microphone, with MBIAS
> providing power. MIC2 and
Hi!
On Fri, Nov 23, 2018 at 02:02:09PM +0100, Paul Kocialkowski wrote:
> This introduces support for HEVC/H.265 to the Cedrus VPU driver, with
> both uni-directional and bi-directional prediction modes supported.
>
> Field-coded (interlaced) pictures, custom quantization matrices and
> 10-bit
Hi!
On Mon, Nov 26, 2018 at 12:23:19AM +0800, Hao Zhang wrote:
> The sun8i R40/T3/V40 PWM has 8 PWM channals and divides to 4 PWM pairs,
> each PWM pair built-in 1 clock module, 2 timer logic module and 1
> programmable dead-time generator, it also support waveform capture.
> It has 2 clock
48 matches
Mail list logo
