On 01/08/2018 06:55 PM, Kieran Bingham wrote:
> The v4l2_mbus_fmt width and height corresponds directly with the
> v4l2_pix_format definitions, yet the differences in documentation make
> it ambiguous what to do in the event of field heights.
>
> Clarify this using the same text as is provided for
On 01/08/2018 07:14 PM, Kieran Bingham wrote:
> The ADV748x handles interlaced media using V4L2_FIELD_ALTERNATE field
> types. The correct specification for the height on the mbus is the
> image height, in this instance, the field height.
>
> The AFE component already correctly adjusts the height
Hi Kieran,
Thanks for your patch.
On 2018-01-08 17:55:24 +, Kieran Bingham wrote:
> The v4l2_mbus_fmt width and height corresponds directly with the
> v4l2_pix_format definitions, yet the differences in documentation make
> it ambiguous what to do in the event of field heights.
>
> Clarify t
Hi Kieran,
Thanks for the update.
On Mon, Jan 08, 2018 at 05:55:24PM +, Kieran Bingham wrote:
> The v4l2_mbus_fmt width and height corresponds directly with the
> v4l2_pix_format definitions, yet the differences in documentation make
> it ambiguous what to do in the event of field heights.
>
From: Sergei Shtylyov
Date: Sun, 07 Jan 2018 00:26:47 +0300
> The TXALCR1 offsets are incorrect in the register offset tables, most
> probably due to copy&paste error. Luckily, the driver never uses this
> register. :-)
>
> Fixes: 4a55530f38e4 ("net: sh_eth: modify the definitions of register"
From: Sergei Shtylyov
Date: Fri, 05 Jan 2018 00:26:46 +0300
> Since the commit 888cc8c20cf ("sh_eth: remove EDMAC_BIG_ENDIAN") (geez,
> I didn't realize that was 2 years ago!) the initializers in the SuperH
> platform code for the 'sh_eth_plat_data::edmac_endian' stopped to matter,
> so we can re
The ADV748x handles interlaced media using V4L2_FIELD_ALTERNATE field
types. The correct specification for the height on the mbus is the
image height, in this instance, the field height.
The AFE component already correctly adjusts the height on the mbus, but
the HDMI component got left behind.
A
Hi Hans, Niklas, Sakari,
Thank you for the very prompt reviews!
I fired the patch - disappeared to teach code club, and came back to the answers
:-D - very streamlined!
On 08/01/18 15:48, Hans Verkuil wrote:
> On 01/08/2018 04:32 PM, Niklas Söderlund wrote:
>> Hi,
>>
>> Thanks for your patch.
>>
Hi Niklas,
On 08/01/18 17:56, Niklas Söderlund wrote:
> Hi Kieran,
>
> Thanks for your patch.
>
> On 2018-01-08 17:39:30 +, Kieran Bingham wrote:
>> The ADV748x handles interlaced media using V4L2_FIELD_ALTERNATE field
>> types. The correct specification for the height on the mbus is the
>>
Hi Niklas,
On Monday, 8 January 2018 19:24:47 EET Niklas Söderlund wrote:
> On 2017-12-08 22:12:56 +0200, Laurent Pinchart wrote:
> > On Friday, 8 December 2017 03:08:35 EET Niklas Söderlund wrote:
> >> In media controller mode all VIN instances needs to be part of the same
> >> media graph. There
Hi Kieran,
Thanks for your patch.
On 2018-01-08 17:39:30 +, Kieran Bingham wrote:
> The ADV748x handles interlaced media using V4L2_FIELD_ALTERNATE field
> types. The correct specification for the height on the mbus is the
> image height, in this instance, the field height.
>
> The AFE comp
The v4l2_mbus_fmt width and height corresponds directly with the
v4l2_pix_format definitions, yet the differences in documentation make
it ambiguous what to do in the event of field heights.
Clarify this using the same text as is provided for the v4l2_pix_format
which is explicit on the matter, an
Hi Niklas,
On Monday, 8 January 2018 18:42:05 EET Niklas Söderlund wrote:
> On 2018-01-08 18:35:23 +0200, Laurent Pinchart wrote:
> > On Wednesday, 20 December 2017 17:20:55 EET Niklas Söderlund wrote:
> >> On 2017-12-14 17:50:24 +0200, Laurent Pinchart wrote:
> >>> On Thursday, 14 December 2017 1
The ADV748x handles interlaced media using V4L2_FIELD_ALTERNATE field
types. The correct specification for the height on the mbus is the
image height, in this instance, the field height.
The AFE component already correctly adjusts the height on the mbus, but
the HDMI component got left behind.
A
Hi Laurent,
Thanks for your comments.
On 2017-12-08 22:12:56 +0200, Laurent Pinchart wrote:
> Hi Niklas,
>
> Thank you for the patch.
>
> On Friday, 8 December 2017 03:08:35 EET Niklas Söderlund wrote:
> > In media controller mode all VIN instances needs to be part of the same
> > media graph.
On 01/08/2018 05:11 PM, Niklas Söderlund wrote:
> On 2018-01-08 16:48:35 +0100, Hans Verkuil wrote:
>> On 01/08/2018 04:32 PM, Niklas Söderlund wrote:
>>> Hi,
>>>
>>> Thanks for your patch.
>>>
>>> On 2018-01-08 17:13:53 +0200, Sakari Ailus wrote:
Hi Kieran,
On Mon, Jan 08, 2018 at 0
Hi Laurent,
On 2018-01-08 18:35:23 +0200, Laurent Pinchart wrote:
> Hi Niklas,
>
> On Wednesday, 20 December 2017 17:20:55 EET Niklas Söderlund wrote:
> > On 2017-12-14 17:50:24 +0200, Laurent Pinchart wrote:
> > > On Thursday, 14 December 2017 16:25:00 EET Sakari Ailus wrote:
> > >> On Fri, Dec
Hi Niklas,
On Wednesday, 20 December 2017 17:20:55 EET Niklas Söderlund wrote:
> On 2017-12-14 17:50:24 +0200, Laurent Pinchart wrote:
> > On Thursday, 14 December 2017 16:25:00 EET Sakari Ailus wrote:
> >> On Fri, Dec 08, 2017 at 10:17:36AM +0200, Laurent Pinchart wrote:
> >>> On Friday, 8 Decemb
On 2018-01-08 16:48:35 +0100, Hans Verkuil wrote:
> On 01/08/2018 04:32 PM, Niklas Söderlund wrote:
> > Hi,
> >
> > Thanks for your patch.
> >
> > On 2018-01-08 17:13:53 +0200, Sakari Ailus wrote:
> >> Hi Kieran,
> >>
> >> On Mon, Jan 08, 2018 at 02:45:49PM +, Kieran Bingham wrote:
> >>> The
On 01/08/2018 04:32 PM, Niklas Söderlund wrote:
> Hi,
>
> Thanks for your patch.
>
> On 2018-01-08 17:13:53 +0200, Sakari Ailus wrote:
>> Hi Kieran,
>>
>> On Mon, Jan 08, 2018 at 02:45:49PM +, Kieran Bingham wrote:
>>> The v4l2_mbus_fmt width and height corresponds directly with the
>>> v4l2_
Hi,
Thanks for your patch.
On 2018-01-08 17:13:53 +0200, Sakari Ailus wrote:
> Hi Kieran,
>
> On Mon, Jan 08, 2018 at 02:45:49PM +, Kieran Bingham wrote:
> > The v4l2_mbus_fmt width and height corresponds directly with the
> > v4l2_pix_format definitions, yet the differences in documentation
Hi Kieran,
On Mon, Jan 08, 2018 at 02:45:49PM +, Kieran Bingham wrote:
> The v4l2_mbus_fmt width and height corresponds directly with the
> v4l2_pix_format definitions, yet the differences in documentation make
> it ambiguous what to do in the event of field heights.
>
> Clarify this by refer
The v4l2_mbus_fmt width and height corresponds directly with the
v4l2_pix_format definitions, yet the differences in documentation make
it ambiguous what to do in the event of field heights.
Clarify this by referencing the v4l2_pix_format which is explicit on the
matter, and by matching the termin
Document support for RZ/A1 SoCs
Signed-off-by: Chris Brandt
Reviewed-by: Geert Uytterhoeven
---
v4:
* Re-added "renesas,usbhs-r7s72100"
v3:
* Removed "renesas,usbhs-r7s72100"
v2:
* Added Reviewed-by
---
Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 2 ++
1 file changed, 2 inserti
This series adds RZ/A1 gadget support to the renesas_usbhs driver.
Basically, it's almost the same HW as the R-Car (and SH) parts.
The only real difference is the some extra registers for the PHY.
This was tested on an RSK board by connecting to a PC as an
Ethernet CDC gadget.
v4:
* Re-added "re
Add USB device support.
Signed-off-by: Chris Brandt
Reviewed-by: Geert Uytterhoeven
---
v4:
* Changed to "renesas,usbhs-r7s72100", "renesas,rza1-usbhs"
v3:
* Changed from "renesas,usbhs-r7s72100" to "renesas,rza1-usbhs"
v2:
* Node name is now generic 'usb@'
* GIC_SPI (73-32) is now just GIC_
This patch adds the capability to support RZ/A1 SoCs.
Signed-off-by: Chris Brandt
---
v2:
* Removed "renesas,usbhs-r7s72100"
* Changed license of rza.c
---
drivers/usb/renesas_usbhs/Makefile | 2 +-
drivers/usb/renesas_usbhs/common.c | 13 ++
drivers/usb/renesas_usbhs/common.h | 6 ++
Hi Chris,
On Mon, Jan 8, 2018 at 12:59 PM, Chris Brandt wrote:
> On Monday, January 08, 2018, Geert Uytterhoeven wrote:
>> Thanks for the update, but I think there has been a misunderstanding.
>> I didn't mean to drop "renesas,usbhs-r7s72100" everywhere, only from
>> the matching in the driver.
>
On Mon, Jan 8, 2018 at 12:59 PM, Chris Brandt wrote:
> Hi Geert and Simon,
>
>
> On Monday, January 08, 2018, Geert Uytterhoeven wrote:
>> Thanks for the update, but I think there has been a misunderstanding.
>> I didn't mean to drop "renesas,usbhs-r7s72100" everywhere, only from
>> the matching i
Hi Geert and Simon,
On Monday, January 08, 2018, Geert Uytterhoeven wrote:
> Thanks for the update, but I think there has been a misunderstanding.
> I didn't mean to drop "renesas,usbhs-r7s72100" everywhere, only from
> the matching in the driver.
Opps, I was all kinds of confused then.
So, b
In general, wakeup settings are not supposed to be changed during any of
the system wide PM phases. The reason is simply that it would break
guarantees provided by the PM core, to properly act on active wakeup
sources.
However, there are exceptions to when, in particular, disabling a device as
wak
On Mon, Jan 8, 2018 at 12:13 PM, Ulf Hansson wrote:
> On 6 January 2018 at 00:57, Rafael J. Wysocki wrote:
>> On Tue, Jan 2, 2018 at 5:08 PM, Ulf Hansson wrote:
>>> In general, wakeup settings are not supposed to be changed during any of
>>> the system wide PM phases. The reason is simply that i
On 6 January 2018 at 00:57, Rafael J. Wysocki wrote:
> On Tue, Jan 2, 2018 at 5:08 PM, Ulf Hansson wrote:
>> In general, wakeup settings are not supposed to be changed during any of
>> the system wide PM phases. The reason is simply that it would break
>> guarantees provided by the PM core, to pr
Hi Simon,
On Mon, Jan 8, 2018 at 9:02 AM, Simon Horman wrote:
> On Fri, Jan 05, 2018 at 03:35:13PM +0100, Geert Uytterhoeven wrote:
>> On Fri, Jan 5, 2018 at 3:04 PM, Simon Horman wrote:
>> > On Wed, Jan 03, 2018 at 01:47:08PM +0100, Geert Uytterhoeven wrote:
>> >> On Wed, Jan 3, 2018 at 1:18 PM
On Fri, Jan 05, 2018 at 03:35:13PM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Fri, Jan 5, 2018 at 3:04 PM, Simon Horman wrote:
> > On Wed, Jan 03, 2018 at 01:47:08PM +0100, Geert Uytterhoeven wrote:
> >> On Wed, Jan 3, 2018 at 1:18 PM, Simon Horman
> >> wrote:
> >> > From: Takeshi Kiha
Hi Simon,
On Mon, Jan 8, 2018 at 7:59 AM, Simon Horman wrote:
> On Fri, Jan 05, 2018 at 04:54:45PM +0100, Niklas Söderlund wrote:
>> This series updates the register size for the thermal hardware. In later
>> versions of the datasheet one additional register is documented. This
>> register is nee
36 matches
Mail list logo
