> -Original Message-
> From: eugen.hris...@microchip.com
> Sent: Friday, February 15, 2019 3:38 AM
> To: linux-media@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; mche...@kernel.org;
> nicolas.fe...@microchip.com; Ken Sloat ;
>
From: Ken Sloat
Update device tree binding documentation specifying how to
enable BT656 with CRC decoding and specify properties for
default parallel bus type.
Signed-off-by: Ken Sloat
---
Changes in v2:
-Use correct media "bus-type" dt property.
Changes in v3:
-Specify defaul
From: Ken Sloat
The ISC driver currently supports ITU-R 601 encoding which
utilizes the external hysync and vsync signals. ITU-R 656
format removes the need for these pins by embedding the
sync pulses within the data packet.
To support this feature, enable necessary register bits
when this
nel.org;
> devicet...@vger.kernel.org
> Subject: Re: [PATCH v2 2/2] media: atmel-isc: Update device tree binding
> documentation
>
> On Fri, Jan 18, 2019 at 06:05:23PM +, Ken Sloat wrote:
> > > -Original Message-
> > > From: Eugen.Hristev@x
> > >
cifying the optional property and value for
Bt.656 where missing. I wanted to open a discussion here first before
doing this though. Thoughts?
Thanks,
Ken Sloat
> -Original Message-
> From: eugen.hris...@microchip.com
> Sent: Friday, January 18, 2019 9:40 AM
> To: Ken Sloat
> Cc: mche...@kernel.org; nicolas.fe...@microchip.com;
> alexandre.bell...@bootlin.com; ludovic.desroc...@microchip.com; linux-
> me...@vge
From: Ken Sloat
The ISC driver currently supports ITU-R 601 encoding which
utilizes the external hysync and vsync signals. ITU-R 656
format removes the need for these pins by embedding the
sync pulses within the data packet.
To support this feature, enable necessary register bits
when this
From: Ken Sloat
Update device tree binding documentation specifying how to
enable BT656 with CRC decoding.
Signed-off-by: Ken Sloat
---
Changes in v2:
-Use correct media "bus-type" dt property.
Documentation/devicetree/bindings/media/atmel-isc.txt | 5 +
1 file changed, 5
> From: Hans Verkuil
> Sent: Tuesday, January 8, 2019 8:46 AM
> To: Ken Sloat ; eugen.hris...@microchip.com
> Cc: mche...@kernel.org; nicolas.fe...@microchip.com;
> alexandre.bell...@bootlin.com; ludovic.desroc...@microchip.com; linux-
> me...@vger.kernel.org
> Subject: Re:
> From: eugen.hris...@microchip.com
> Sent: Monday, January 7, 2019 6:10 AM
> To: Ken Sloat
> Cc: mche...@kernel.org; nicolas.fe...@microchip.com;
> alexandre.bell...@bootlin.com; ludovic.desroc...@microchip.com; linux-
> me...@vger.kernel.org
> Subject: Re: [PATCH v1 1/2]
From: Ken Sloat
The ISC driver currently supports ITU-R 601 encoding which
utilizes the external hysync and vsync signals. ITU-R 656
format removes the need for these pins by embedding the
sync pulses within the data packet.
To support this feature, enable necessary register bits
when this
From: Ken Sloat
Update device tree binding documentation specifying how to
enable BT656 with CRC decoding.
Signed-off-by: Ken Sloat
---
Documentation/devicetree/bindings/media/atmel-isc.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/atmel
> On 21.11.2018 16:50, Ken Sloat wrote:
> >>> From: Ken Sloat
> >>>
> >>> In some usages isc->raw_fmt will not be initialized. If this is the
> >>> case, it is very possible that a NULL struct de-reference will
> >>> occur, as this
>> From: Ken Sloat
>>
>> In some usages isc->raw_fmt will not be initialized. If this is the
>> case, it is very possible that a NULL struct de-reference will occur,
>> as this member is referenced many times.
> Hello Ken,
> Do you have any confidence t
From: Ken Sloat
In some usages isc->raw_fmt will not be initialized. If this
is the case, it is very possible that a NULL struct de-reference
will occur, as this member is referenced many times.
To prevent this, add safety checks for this member and handle
situations accordingly.
Signed-off
> Hello Ken,
>
> Indeed this is a bug, I saw it before as well, but so far, this has not
> appeared with the sensors we have connected. I have been trying to get around
> to fix it, but it's not a simple fix, much rather a rework of the driver part
> that handles the
b6fbcfa4
3fe0: bebd7be0 bebd7bd0 0001fe10 b6ef2130
Code: e5d4200e e352 0abe e59725c0 (e592a004)
---[ end trace fdc3db2f91ac07c6 ]---
Thanks,
Ken Sloat
essages that
seem to trace back to :
au0828: start_urb_transfer: failed big buffer allocation, err = -12
This is a Fedora 22 system ( Linux 4.2.3-200.fc22.i686+PAE )
Attached is dmesg output.
Any tips are appreciated.
Thanks,
Ken
[ 1255.279886] usb 2-1.3: new high-speed USB device num
gauge suitable all type of battery
4. Universal battery BMS: 3S-8S all in one model, 4S-16S all in one model
More details, pls check our web and contact us if you have interest.
Hope to establish the long-term cooperation realithionship with you. Thanks.
Ken
Email: ejtechgr...@yeah.net
Skype
Ken Smith wrote:
First post to this list, but not new to Linux.
I'm trying to get a Compro VideoMate S350 card to work in a 32bit
Centos 5.5 system that also has a Hauppauge WinTV-NOVA-T-500 that uses
the dvb-usb-dib0700.ko kernel module as its driver. The Nova-T appears
to be wo
deo-buf.ko
WARNING: Error inserting video_buf
(/lib/modules/2.6.18-194.32.1.el5/kernel/drivers/media/video/video-buf.ko):
Invalid module format
I'm sure I have missed something obvious, I'd appreciate any suggestions.
Thanks
Ken
--
This message has been scanned for viruses and
21 matches
Mail list logo
