On Mon, Oct 07, 2019 at 07:11:03PM +0800, Chen-Yu Tsai wrote:
> On Mon, Oct 7, 2019 at 7:09 PM Maxime Ripard wrote:
> >
> > Hi,
> >
> > On Fri, Oct 04, 2019 at 02:33:41PM +0800, Chen-Yu Tsai wrote:
> > > On Fri, Oct 4, 2019 at 12:37 AM Maxime Ripard wrote:
&
Hi,
On Fri, Oct 04, 2019 at 02:33:41PM +0800, Chen-Yu Tsai wrote:
> On Fri, Oct 4, 2019 at 12:37 AM Maxime Ripard wrote:
> > On Thu, Oct 03, 2019 at 11:51:05PM +0800, Chen-Yu Tsai wrote:
> > > On Thu, Oct 3, 2019 at 11:48 PM Maxime Ripard wrote:
> > > >
>
Hi,
On Thu, Oct 03, 2019 at 11:51:05PM +0800, Chen-Yu Tsai wrote:
> On Thu, Oct 3, 2019 at 11:48 PM Maxime Ripard wrote:
> >
> > It turns out that what was thought to be the module clock was actually the
> > clock meant to be used by the sensor, and isn't playing
A10 CSI binding")
Reported-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
.../devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git
a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml
b/Documentation
quot;)
Reported-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun7i-a20.dtsi | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 874231be04e4..8aebefd6accf 100644
--- a/arch/arm/boo
The linux,rc-map-name property is described using an enum, yet a value has
been put in that enum twice, resulting in a warning. Let's fix that.
Fixes: 7c31b9d67342 ("media: dt-bindings: media: Add YAML schemas for the
generic RC bindings")
Signed-off-by: Maxime Ripard
---
please confirm if you want to attend this session. I didn't find
> > > an email with explicit confirmation, so it was probably done via irc. But
> > > since
> > > this session is getting close to capacity I would prefer to keep
> > > attendance to
> >
running sparse I get this warning:
>
> drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c:21:31: warning: symbol
> 'sun4i_csi_formats' was not declared. Should it be static?
>
> Can you post a follow-up patch for this?
Sorry for that, I just sent a patch fixing it.
Maxi
From: Maxime Ripard
The sun4i_csi_formats array is only used in sun4i_v4l2.c, so it doesn't
make any sense to have it !static.
Reported-by: Hans Verkuil
Signed-off-by: Maxime Ripard
---
drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c | 2 +-
1 file changed, 1 insertion(+), 1 del
On Thu, Aug 22, 2019 at 10:21:11AM +0200, Maxime Ripard wrote:
> From: Maxime Ripard
>
> Hi,
>
> Here is a series introducing the support for the A10 (and SoCs of the same
> generation) CMOS Sensor Interface (called CSI, not to be confused with
> MIPI-CSI, which isn
Hi Sean,
On Tue, Aug 20, 2019 at 09:15:26AM +0100, Sean Young wrote:
> On Mon, Aug 19, 2019 at 08:26:18PM +0200, Maxime Ripard wrote:
> > From: Maxime Ripard
> >
> > The RC controllers have a bunch of generic properties that are needed in a
> > device tree. A
77f ("media: dt-bindings: media: Add vendor prefix for allegro")
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
b/Documentation/d
; popping-up soon.
> very shortly [2].
>
> To avoid confusing the patches here with those on v2 [1], I'm marking them as
> v3.
You might have missed it, but have you looked at the RFC "drm: Split
out the formats API and move it to a common place" I sent a couple of
weeks
rame
- Removed the unused neighbor info buffer
- Made sure to have the same structure offset and alignments across
32 bits and 64 bits architecture
Maxime Ripard (1):
media: cedrus: Add H264 decoding support
Pawel Osciak (1):
media: uapi: Add H264 low-level decoder API compound contr
the kernel.
Co-Developped-by: Maxime Ripard
Signed-off-by: Pawel Osciak
Signed-off-by: Guenter Roeck
Signed-off-by: Maxime Ripard
---
Documentation/media/uapi/v4l/biblio.rst| 9 +-
Documentation/media/uapi/v4l/ext-ctrls-codec.rst | 549 ++-
Documentation/media/uapi
Introduce some basic H264 decoding support in cedrus. So far, only the
baseline profile videos have been tested, and some more advanced features
used in higher profiles are not even implemented.
Reviewed-by: Jernej Skrabec
Signed-off-by: Maxime Ripard
---
drivers/staging/media/sunxi/cedrus
Hi,
On Tue, Mar 05, 2019 at 06:05:08PM +0100, Jernej Škrabec wrote:
> Dne torek, 05. marec 2019 ob 11:17:32 CET je Maxime Ripard napisal(a):
> > Hi Jernej,
> >
> > On Wed, Feb 20, 2019 at 06:50:54PM +0100, Jernej Škrabec wrote:
> > > I really wanted to do another
On Fri, Feb 22, 2019 at 04:46:17PM +0900, Tomasz Figa wrote:
> Hi Maxime,
>
> On Wed, Feb 20, 2019 at 11:17 PM Maxime Ripard
> wrote:
> >
> > From: Pawel Osciak
> >
> > Stateless video codecs will require both the H264 metadata and slices in
> > order
ter
on. Especially when new stacks are going to be developped on top of
this, I'm sure we're going to have plenty of bugs to address :)
> Dne sreda, 20. februar 2019 ob 15:17:34 CET je Maxime Ripard napisal(a):
> > Introduce some basic H264 decoding support in cedrus. So far,
Hi,
On Mon, Mar 04, 2019 at 03:49:11PM -0300, Ezequiel Garcia wrote:
> On Wed, 2019-02-20 at 15:17 +0100, Maxime Ripard wrote:
> > From: Pawel Osciak
> >
> > Stateless video codecs will require both the H264 metadata and slices in
> > order to be able to decode frame
t?
>
> Also regarding the pixel formats. I still think we should have two
> pixel formats: V4L2_PIX_FMT_H264_SLICE_RAW and
> V4L2_PIX_FMT_H264_SLICE_ANNEX_B, to properly represent "raw" NALUs
> and "annex B" formatted NALUs.
I agree with that, but I was under the impression that it would be
part of your series, since you would be the prime user (at first at
least).
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
On Mon, Feb 25, 2019 at 10:21:51AM +0100, Jacopo Mondi wrote:
> Hello Maxime, Benoit,
> sorry for chiming in, but I'm a bit confused...
>
> On Fri, Feb 22, 2019 at 04:04:21PM +0100, Maxime Ripard wrote:
> > On Fri, Feb 22, 2019 at 08:54:56AM -0600, Benoit Parrot wro
On Fri, Feb 22, 2019 at 08:54:56AM -0600, Benoit Parrot wrote:
> Maxime Ripard wrote on Fri [2019-Feb-22 15:39:59
> +0100]:
> > On Thu, Feb 21, 2019 at 10:20:20AM -0600, Benoit Parrot wrote:
> > > Hi Maxime,
> > >
> > > A couple of questions,
> > &
On Thu, Feb 21, 2019 at 10:20:20AM -0600, Benoit Parrot wrote:
> Hi Maxime,
>
> A couple of questions,
>
> Maxime Ripard wrote on Thu [2018-Oct-11 04:21:00
> -0500]:
> > The clock rate, while hardcoded until now, is actually a function of the
> > resolution, fram
the kernel.
Co-Developped-by: Maxime Ripard
Signed-off-by: Pawel Osciak
Signed-off-by: Guenter Roeck
Signed-off-by: Maxime Ripard
---
Documentation/media/uapi/v4l/biblio.rst| 9 +-
Documentation/media/uapi/v4l/extended-controls.rst | 547 ++-
Documentation/media/uapi
Introduce some basic H264 decoding support in cedrus. So far, only the
baseline profile videos have been tested, and some more advanced features
used in higher profiles are not even implemented.
Signed-off-by: Maxime Ripard
---
drivers/staging/media/sunxi/cedrus/Makefile | 3 +-
drivers
- Removed the unused neighbor info buffer
- Made sure to have the same structure offset and alignments across
32 bits and 64 bits architecture
Maxime Ripard (1):
media: cedrus: Add H264 decoding support
Pawel Osciak (1):
media: uapi: Add H264 low-level decoder API compound controls.
Docu
0900, Tomasz Figa wrote:
> > > > Hi Maxime,
> > > >
> > > > On Mon, Feb 11, 2019 at 11:39 PM Maxime Ripard
> > > > wrote:
> > > > > Hi,
> > > > >
> > > > > Here is a new version of the H264 decoding support in
d to h265 since, but considering 4k doesn't
seem unreasonable.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
On Mon, Feb 11, 2019 at 04:48:17PM -0300, Ezequiel Garcia wrote:
> On Mon, 2019-02-11 at 15:39 +0100, Maxime Ripard wrote:
> > Introduce some basic H264 decoding support in cedrus. So far, only the
> > baseline profile videos have been tested, and some more advanced features
>
, so I guess we should protect
that by a check on whether that control has been set or not. What do
you think?
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
On Mon, Feb 11, 2019 at 02:12:25PM -0300, Ezequiel Garcia wrote:
> On Mon, 2019-02-11 at 15:39 +0100, Maxime Ripard wrote:
> >
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > index d6eed479c3a6..6fc955926bdb 100644
> > --- a/inc
buffer in order to have one slot per frame
- Removed the unused neighbor info buffer
- Made sure to have the same structure offset and alignments across
32 bits and 64 bits architecture
Maxime Ripard (1):
media: cedrus: Add H264 decoding support
Pawel Osciak (1):
media: uapi: Add
Introduce some basic H264 decoding support in cedrus. So far, only the
baseline profile videos have been tested, and some more advanced features
used in higher profiles are not even implemented.
Signed-off-by: Maxime Ripard
---
drivers/staging/media/sunxi/cedrus/Makefile | 3 +-
drivers
the kernel.
Co-Developed-by: Maxime Ripard
Signed-off-by: Pawel Osciak
Signed-off-by: Guenter Roeck
Signed-off-by: Maxime Ripard
---
Documentation/media/uapi/v4l/biblio.rst| 9 +-
Documentation/media/uapi/v4l/extended-controls.rst | 530 ++-
Documentation/media/uapi
ually very different usages for each IP (the RAM
controls the DMA side of the IP, the mod one controls the "logic" part
of it, the bus one the register, etc.) so they needed to be handled
quite differently. I'd rather stick with the current API.
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
Hi Kishon,
On Wed, Feb 06, 2019 at 06:00:19PM +0530, Kishon Vijay Abraham I wrote:
> On 06/02/19 5:55 PM, Maxime Ripard wrote:
> > On Wed, Feb 06, 2019 at 05:43:12PM +0530, Kishon Vijay Abraham I wrote:
> >> On 05/02/19 2:16 PM, Daniel Vetter wrote:
> >>> On Mon, Fe
On Thu, Feb 07, 2019 at 09:44:46AM +0100, Paul Kocialkowski wrote:
> Hi,
>
> On Mon, 2019-01-21 at 16:45 +0100, Maxime Ripard wrote:
> > The current configuration of the DSI bridge and its associated D-PHY is
> > intertwined. In order to ease the future conversion to the phy
elease() always returns 0. I guess it could be changed to return
> void. The reason it has int is that it could be used as the release
> callback as such.
>
> > + v4l2_pipeline_pm_use(&csi->vdev.entity, 0);
> > + pm_runtime_put(csi->dev);
> > +
> > + mutex_unlock(&csi->lock);
> > +
> > + return ret;
> > +}
Do you want me to change the construct then?
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Hi Kishon,
On Wed, Feb 06, 2019 at 05:43:12PM +0530, Kishon Vijay Abraham I wrote:
> On 05/02/19 2:16 PM, Daniel Vetter wrote:
> > On Mon, Feb 04, 2019 at 03:33:31PM +0530, Kishon Vijay Abraham I wrote:
> >>
> >>
> >> On 21/01/19 9:15 PM, Maxime Ripard wrote:
Hi Kishon,
On Mon, Feb 04, 2019 at 03:33:31PM +0530, Kishon Vijay Abraham I wrote:
> On 21/01/19 9:15 PM, Maxime Ripard wrote:
> > Here is a set of patches to allow the phy framework consumers to test and
> > apply runtime configurations.
> >
> > This is needed to su
t; order the sensor is sending data in.
>
> Signed-off-by: Chen-Yu Tsai
Acked-by: Maxime Ripard
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
t;
> Fixes: 5cc7522d8965 ("media: sun6i: Add support for Allwinner CSI V3s")
> Cc:
> Signed-off-by: Chen-Yu Tsai
Acked-by: Maxime Ripard
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
ng. Maybe we could end with a spectrum of
> > capabilities that would allow us to cover the range from fully
> > stateless to fully stateful IPs more smoothly. Right now we have two
> > specifications that only consider the extremes of that range.
>
> I gave it a bit more
On Mon, Jan 28, 2019 at 09:55:03PM +0100, Jernej Skrabec wrote:
> Add a node for H6 SRAM C1 section.
>
> Manual calls it VE SRAM, but for consistency with older SoCs, SRAM C1
> name is used.
>
> Signed-off-by: Jernej Skrabec
Applied, thanks!
Maxime
--
Maxime Ripard, Boot
On Mon, Jan 28, 2019 at 09:55:02PM +0100, Jernej Skrabec wrote:
> This introduces a new compatible for the H6 SRAM C1 section, that is
> compatible with the SRAM C1 section as found on the A10.
>
> Signed-off-by: Jernej Skrabec
Applied, thanks!
Maxime
--
Maxime Ripard, Bootlin
Em
On Mon, Jan 28, 2019 at 09:55:01PM +0100, Jernej Skrabec wrote:
> H6 has improved VPU. It supports 10-bit HEVC decoding and AFBC output
> format for HEVC.
>
> Signed-off-by: Jernej Skrabec
Acked-by: Maxime Ripard
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engin
On Mon, Jan 28, 2019 at 09:55:00PM +0100, Jernej Skrabec wrote:
> H6 VPU doesn't work if DMA offset is set.
>
> Add a quirk for it.
>
> Signed-off-by: Jernej Skrabec
Acked-by: Maxime Ripard
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
On Mon, Jan 28, 2019 at 09:54:59PM +0100, Jernej Skrabec wrote:
> This adds a compatible for H6. H6 VPU supports 10-bit HEVC decoding and
> additional AFBC output format for HEVC.
>
> Signed-off-by: Jernej Skrabec
Acked-by: Maxime Ripard
Maxime
--
Maxime Ripard, Bootlin
Embedd
On Mon, Jan 28, 2019 at 09:33:04AM +0100, Jacopo Mondi wrote:
> Hi everyone,
>
> On Mon, Jan 28, 2019 at 01:20:37PM +0530, Jagan Teki wrote:
> > On Fri, Jan 25, 2019 at 9:10 PM Maxime Ripard
> > wrote:
> > >
> > > On Thu, Jan 24, 2019 at 11:28:01
-specific structures. Can't we
> consider that in this specific instance, the hardware-specific
> structure just happens to be identical to the original bitstream
> format?
>
> I agree that this is not strictly optimal for that particular
> hardware, but such is the cost of abstractions, and in this specific
> case I don't believe the cost would be particularly high?
I mean, that argument can be made for the rockchip driver as well. If
reconstructing the bitstream is something we can do, and if we don't
care about being suboptimal for one particular hardware, then why the
rockchip driver doesn't just recreate the bitstream from that API?
After all, this is just a hardware specific header that happens to be
identical to the original bitstream format
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
The Makefile and Kconfig for the sun6i CSI driver are included in the main
Makefile / KConfig file. Since we're going to add a new CSI driver for an
older chip, and the Cedrus driver eventually, it makes more sense to put
those in our directory.
Signed-off-by: Maxime Ripard
---
drivers/
patible instead
- Fix an issue on the last frame where we would not have any buffer
queued and would report an error by using a scratch buffer
- Fix the warnings reported by v4l2-compliance
- Rebase on top of 5.0-rc1
- Added a MAINTAINERS entry
- Switched to strscpy
- Fixed SPDX he
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun7i-a20-bananapi.dts | 94 +-
1 file changed, 94 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 556b1b591c5d..f5fee1f95900 100644
--- a/arch/arm
ff-by: Maxime Ripard
---
MAINTAINERS | 8 +-
drivers/media/platform/sunxi/Kconfig| 1 +-
drivers/media/platform/sunxi/Makefile | 1 +-
drivers/media/platform/sunxi/sun4i-csi/Kconfig | 12 +-
drivers/media/platform/
The Allwinner A10 CMOS Sensor Interface is a camera capture interface also
used in later (A10s, A13, A20, R8 and GR8) SoCs.
On some SoCs, like the A10, there's multiple instances of that controller,
with one instance supporting more channels and having an ISP.
Signed-off-by: Maxime R
The CSI controller embedded in the A20 can be supported by our new driver.
Let's add it to our DT.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun7i-a20.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7
On Mon, Jan 28, 2019 at 02:28:45PM +0530, Jagan Teki wrote:
> 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
> Ac
clock rate.
>
> Signed-off-by: Jagan Teki
Acked-by: Maxime Ripard
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
On Fri, Jan 25, 2019 at 10:49:58AM +0800, Chen-Yu Tsai wrote:
> On Fri, Jan 25, 2019 at 2:57 AM Jernej Škrabec
> wrote:
> >
> > Dne ponedeljek, 21. januar 2019 ob 10:57:57 CET je Chen-Yu Tsai napisal(a):
> > > On Mon, Jan 21, 2019 at 5:50 PM Maxime Ri
On Thu, Jan 24, 2019 at 11:37:34PM +0530, Jagan Teki wrote:
> 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
Acked
set_power(struct sun6i_csi *csi, bool
> enable)
> clk_disable_unprepare(sdev->clk_ram);
> clk_mod_disable:
> clk_disable_unprepare(sdev->clk_mod);
> +clk_mod_put:
> + if (of_device_is_compatible(dev->of_node, "allwinner,sun50i-a64-csi"))
> + clk_rate_exclusive_put(sdev->clk_mod);
> return ret;
The sequence in the error path and in the disable path aren't the same, why?
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
gt;
> Reviewed-by: Rob Herring
> Signed-off-by: Jagan Teki
Acked-by: Maxime Ripard
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
ssion, but what regression is there exactly (ie,
what was working before that commit that doesn't work anymore?). What
tools/commands are you using to see this behaviour?
It really isn't obvious from your patch and the patch you mention what
could go wrong or be improved.
Maxime
--
Max
ce won’t track the previous result. But you have no
> idea on what data the device would need to process this picture. It
> is hard to define a standard structure for it.
>
> As you see, even allwinner doesn’t obey all the standard the IOS
> document said.
It's not that it disobeys it, it's that it requires the full blown DPB
to have a working driver.
> In my original suggestion, I would just to add more reservation
> fields then future driver can use it.
This interface is not stable at the moment, so it doesn't really
matter does it?
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
Hi,
On Thu, Jan 24, 2019 at 02:10:25PM +0100, Paul Kocialkowski wrote:
> On Tue, 2018-11-27 at 09:21 +0100, Maxime Ripard wrote:
> > Hi!
> >
> > On Fri, Nov 23, 2018 at 02:02:09PM +0100, Paul Kocialkowski wrote:
> > > This introduces support for HEVC/H.265
bottom_field_order_cnt;
> > > > + __u8 flags; /* V4L2_H264_DPB_ENTRY_FLAG_* */
> > > > +};
> > > > +
> > > > +struct v4l2_ctrl_h264_decode_param {
> > > > + __u32 num_slices;
> > > > + __u8 idr_pic_flag;
> > > > + __u8 nal_ref_idc;
> > > > + __s32 top_field_order_cnt;
> > > > + __s32 bottom_field_order_cnt;
> > > > + __u8 ref_pic_list_p0[32];
> > > > + __u8 ref_pic_list_b0[32];
> > > > + __u8 ref_pic_list_b1[32];
> > >
> > > I would prefer to keep only two list, list0 and list 1.
> >
> > I'm not even sure why this is needed in the first place
> > anymore. It's not part of the bitstream, and it seems to come from
> > ChromeOS' Rockchip driver that uses it though. Do you know why?
>
> You see the P frame would use only a list and B for two list. So for
> the parameter of a picture, two lists are max. I would suggest only
> keep two arrays here and rename them as list0 and list1, it would
> reduce the conflict.
Right, but those lists are already in v4l2_ctrl_h264_slice_param (with
the construct you are suggesting). I'm not sure about why the
redundancy is needed. Alex, Tomasz, do you have any idea why this was
needed at some point?
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
.
http://code.bulix.org/9au998-562745?raw
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
The lanes parameter is not solely about the number of lanes, but it also
carries the fact that those are the first lanes in use during the
transmission.
It was implicit so far, so make sure it's explicit now.
Suggested-by: Sakari Ailus
Acked-by: Sakari Ailus
Signed-off-by: Maxime R
Now that we have everything in place in the PHY framework to deal in a
generic way with MIPI D-PHY phys, let's convert our PHY driver and its
associated DSI driver to that new API.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Kconfig | 11 +-
drivers/gpu/drm/sun4i/Mak
The Init and wakeup D-PHY parameters are in the micro/milliseconds range,
putting the values real close to the types limits if they were in
picoseconds.
Move them to microseconds which should be better fit.
Suggested-by: Sakari Ailus
Acked-by: Sakari Ailus
Signed-off-by: Maxime Ripard
-EOPNOTSUPP in phy_configure and phy_validate when the operation
is not implemented
Maxime Ripard (9):
phy: dphy: Remove unused header
phy: dphy: Change units of wakeup and init parameters
phy: dphy: Clarify lanes parameter documentation
sun6i: dsi: Convert to generic phy handling
phy:
Now that our MIPI D-PHY driver has been converted to the phy framework,
let's move it into the drivers/phy directory.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Kconfig | 10 +-
drivers/gpu/drm/sun4i/Makefile | 1 +-
drivers/gpu/drm/
The Cadence D-PHY bindings was defined as part of the DSI block so far.
However, since it's now going to be a separate driver, we need to move the
binding to a file of its own.
Acked-by: Sakari Ailus
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/display/bridge/cdns,ds
The videomode.h header inclusion is an artifact from the patches
development, remove it.
Suggested-by: Sakari Ailus
Acked-by: Sakari Ailus
Signed-off-by: Maxime Ripard
---
include/linux/phy/phy-mipi-dphy.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/phy/phy-mipi-dphy.h
Now that we have everything we need in the phy framework to allow to tune
the phy parameters, let's convert the Cadence DSI bridge to that API
instead of creating a ad-hoc driver for its phy.
Acked-by: Sean Paul
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/Kconfig
The current configuration of the DSI bridge and its associated D-PHY is
intertwined. In order to ease the future conversion to the phy framework
for the D-PHY part, let's split the configuration in two.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/cdns-dsi.c
support available to all these drivers, without having to
duplicate that code three times, let's create a generic phy framework
driver.
Acked-by: Sakari Ailus
Signed-off-by: Maxime Ripard
---
drivers/phy/cadence/Kconfig | 13 +-
drivers/phy/cadence/Makefile| 1 +-
drivers/phy/ca
E_OVERHEAD);
>
> We're throwing away the mode_valid_check switch here to flip between crtc_h*
> value and h* value. Is that intentional? We're using it above for hdisplay, so
> it's a bit confusing.
ah, right, thanks for spotting this.
I'll resend a version with tho
Hi Sean,
On Thu, Jan 17, 2019 at 08:53:22AM -0500, Sean Paul wrote:
> On Wed, Jan 09, 2019 at 10:33:25AM +0100, Maxime Ripard wrote:
> > + opts->wakeup = cdns_dphy_get_wakeup_time_ns(dphy) * 1000;
>
> This should be "/ 1000" since the units of wakeup is us now (tha
x27;s much easier to
deal with.
I'd really like to have that pattern for all the IPs even if we didn't
spot any issue, since we can't really say that the datasheet are
complete, and one can always make a mistake and overlook something.
I'm fine with this version, and
Hi,
On Wed, Jan 09, 2019 at 01:01:22AM +0800, ayaka wrote:
> On 1/8/19 5:52 PM, Randy 'ayaka' Li wrote:
> > On Thu, Nov 15, 2018 at 03:56:49PM +0100, Maxime Ripard wrote:
> > > From: Pawel Osciak
> > >
> > > Stateless video codecs will require both
e useful, this is
really out of scope for this series.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
gt; + __s32 top_field_order_cnt;
> > + __s32 bottom_field_order_cnt;
> > + __u8 flags; /* V4L2_H264_DPB_ENTRY_FLAG_* */
> > +};
> > +
> > +struct v4l2_ctrl_h264_decode_param {
> > + __u32 num_slices;
> > + __u8 idr_pic_flag;
> > + __u8 na
On Fri, Jan 11, 2019 at 11:54:12AM +0530, Jagan Teki wrote:
> On Mon, Jan 7, 2019 at 6:59 PM Maxime Ripard
> wrote:
> > On Mon, Dec 24, 2018 at 08:57:48PM +0530, Jagan Teki wrote:
> > > On Fri, Dec 21, 2018 at 6:30 PM Maxime Ripard
> > > wrote:
> > >
- Remove the mode parameter from phy_configure
- Added phy_configure and phy_validate stubs
- Return -EOPNOTSUPP in phy_configure and phy_validate when the operation
is not implemented
Maxime Ripard (9):
phy: dphy: Remove unused header
phy: dphy: Change units of wakeup and init paramet
The videomode.h header inclusion is an artifact from the patches
development, remove it.
Suggested-by: Sakari Ailus
Signed-off-by: Maxime Ripard
---
include/linux/phy/phy-mipi-dphy.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/phy/phy-mipi-dphy.h
b/include/linux/phy/phy
The lanes parameter is not solely about the number of lanes, but it also
carries the fact that those are the first lanes in use during the
transmission.
It was implicit so far, so make sure it's explicit now.
Suggested-by: Sakari Ailus
Signed-off-by: Maxime Ripard
---
include/linux/ph
Now that we have everything in place in the PHY framework to deal in a
generic way with MIPI D-PHY phys, let's convert our PHY driver and its
associated DSI driver to that new API.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Kconfig | 11 +-
drivers/gpu/drm/sun4i/Mak
Now that we have everything we need in the phy framework to allow to tune
the phy parameters, let's convert the Cadence DSI bridge to that API
instead of creating a ad-hoc driver for its phy.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/Kconfig| 1 +-
drivers/gpu/drm/b
The Cadence D-PHY bindings was defined as part of the DSI block so far.
However, since it's now going to be a separate driver, we need to move the
binding to a file of its own.
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
Now that our MIPI D-PHY driver has been converted to the phy framework,
let's move it into the drivers/phy directory.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Kconfig | 10 +-
drivers/gpu/drm/sun4i/Makefile | 1 +-
drivers/gpu/drm/
support available to all these drivers, without having to
duplicate that code three times, let's create a generic phy framework
driver.
Signed-off-by: Maxime Ripard
---
drivers/phy/cadence/Kconfig | 13 +-
drivers/phy/cadence/Makefile| 1 +-
drivers/phy/cadence/cdns-dphy.c
The Init and wakeup D-PHY parameters are in the micro/milliseconds range,
putting the values real close to the types limits if they were in
picoseconds.
Move them to microseconds which should be better fit.
Suggested-by: Sakari Ailus
Signed-off-by: Maxime Ripard
---
drivers/phy/phy-core-mipi
The current configuration of the DSI bridge and its associated D-PHY is
intertwined. In order to ease the future conversion to the phy framework
for the D-PHY part, let's split the configuration in two.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/cdns-dsi.c
On Mon, Dec 24, 2018 at 08:57:48PM +0530, Jagan Teki wrote:
> On Fri, Dec 21, 2018 at 6:30 PM Maxime Ripard
> wrote:
> >
> > On Thu, Dec 20, 2018 at 06:24:34PM +0530, Jagan Teki wrote:
> > > Unfortunately default CSI_SCLK rate cannot work properly to
> > >
ke any sense to do it in the probe function...
We discussed this in the previous iteration already.
What we didn't discuss is the variant function that you introduce,
while the previous approach was enough.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On Mon, Dec 17, 2018 at 10:20:39PM +0200, sakari.ai...@iki.fi wrote:
> Hi Maxime,
>
> On Mon, Dec 17, 2018 at 04:49:21PM +0100, Maxime Ripard wrote:
> > Hi Sakari,
> >
> > Thanks for your feedback.
> >
> > On Thu, Dec 13, 2018 at 10:4
65;5402;1c
On Wed, Dec 19, 2018 at 04:11:50PM +0530, Jagan Teki wrote:
> On Wed, Dec 19, 2018 at 3:55 PM Maxime Ripard
> wrote:
> >
> > On Tue, Dec 18, 2018 at 08:58:22PM +0530, Jagan Teki wrote:
> > > On Tue, Dec 18, 2018 at 8:51 PM Maxime Ripard
> > > w
On Tue, Dec 18, 2018 at 08:58:22PM +0530, Jagan Teki wrote:
> On Tue, Dec 18, 2018 at 8:51 PM Maxime Ripard
> wrote:
> >
> > On Tue, Dec 18, 2018 at 05:03:14PM +0530, Jagan Teki wrote:
> > > This series support CSI on Allwinner A64.
> > >
> > > Tes
1 - 100 of 560 matches
Mail list logo
