Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of
On 18/03/14 01:30, Laurent Pinchart wrote: I agree with you. I know that DT bindings review takes too much time, slows development down and is just generally painful. I'm trying to reply to this e- mail thread as fast as possible, but I'm also busy with other tasks :-/ The lack of formal consensus comes partly from the fact that people are busy and that the mail thread is growing big. There's still two open questions from my view of the whole discussion: - Do we really want to drop bidirectional links ? Grant has been pretty vocal about that, but there has been several replies with arguments for bidirectional links, and no reply from him afterwards. Even though that wouldn't be the preferred solution for everybody, there doesn't seem to be a strong disagreement about dropping bidirectional links, as long as we can come up with a reasonable implementation. - If we drop bidirectional links, what link direction do we use ? There has been several proposals (including north, which I think isn't future-proof as it assumes an earth-centric model) and no real agreement, although there seems to be a consensus among several developers that the core OF graph bindings could leave that to be specified by subsystem bindings. We would still have to agree on a direction for the display subsystem of course. If my above explanation isn't too far from the reality the next step could be to send a new version of the DT bindings proposal as a ping. I agree with the above. However, I also think we should just go forward with the bidirectional links for now. The bindings for bidir links are already in the mainline kernel, so they can't be seen as broken. When we have an agreement about the direction, and we've got common parsing code, it's trivial to convert the existing links to single direction links, and the old dts files with bidir links continue to work fine. This is what I'm planning to do with OMAP display subsystem, as I _really_ want to get the DT support merged for 3.15. The current mix of pdata + DT that we have for OMAP display is an unmaintainable mess. So unless I get a nack from someone (I've pinged Grant twice about this), or someone explains why it's a bad idea, I'll push the OMAP display bindings [1] for 3.15 with bidir bindings, and change them to single-dir later. Note that I did remove the abbreviated endpoint format that I had there earlier, so now the bindings are fully compatible with the v4l2 bindings. Tomi [1] http://article.gmane.org/gmane.linux.drivers.devicetree/63885 signature.asc Description: OpenPGP digital signature
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
Hi,
Laurent Pinchart wrote:
Hi Lothar,
On Monday 17 March 2014 16:14:36 Lothar Waßmann wrote:
Laurent Pinchart wrote:
On Monday 17 March 2014 14:41:09 Andrzej Hajda wrote:
On 03/13/2014 06:17 PM, Denis Carikli wrote:
We need a way to pass signal polarity informations
between DRM panels, and the display drivers.
To do that, a pol_flags field was added to drm_display_mode.
Signed-off-by: Denis Carikli de...@eukrea.com
---
ChangeLog v10-v11:
- Since the imx-drm won't be able to retrive its regulators
from the device tree when using display-timings nodes,
and that I was told that the drm simple-panel driver
already supported that, I then, instead, added what was
lacking to make the eukrea displays work with the
drm-simple-panel driver.
That required a way to get back the display polarity
informations from the imx-drm driver without affecting
userspace.
---
include/drm/drm_crtc.h |8
1 file changed, 8 insertions(+)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f764654..61a4fe1 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -131,6 +131,13 @@ enum drm_mode_status {
#define DRM_MODE_FLAG_3D_MAX DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
+#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGEBIT(1)
+#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGEBIT(2)
+#define DRM_MODE_FLAG_POL_PIXDATA_PRESERVE BIT(3)
+#define DRM_MODE_FLAG_POL_DE_NEGEDGE BIT(4)
+#define DRM_MODE_FLAG_POL_DE_POSEDGE BIT(5)
+#define DRM_MODE_FLAG_POL_DE_PRESERVEBIT(6)
Could you add some description to these flags.
What are *_PRESERVE flags for?
Are those flags 1:1 compatible with respective 'videomode:flags'?
I guess DE flags should be rather DRM_MODE_FLAG_POL_DE_(LOW|HIGH), am I
right?
Possibly nitpicking, I wouldn't call the clock edge on which data signals
are generated/sampled data polarity. This is clock polarity
information.
Have you seen cases where pixel data and DE are geenrated or need to be
sampled on different edges ?
DE is not a clock signal, but an 'Enable' signal whose value (high or
low) defines the window in which the pixel data is valid.
The flag defines whether data is valid during the HIGH or LOW period of
DE.
The DRM_MODE_FLAG_POL_DE_(LOW|HIGH) do, by my impression of the proposed new
DRM_MODE_FLAG_POL_DE_*EDGE flags is that they define sampling clock edges,
not
active levels.
The current naming of the flags gives the impression that they describe
the sampling edges of a clock signal. But the DE signal in fact is not
a clock signal but a level sensitive gating signal.
Lothar Waßmann
--
___
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | i...@karo-electronics.de
___
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] s5p-mfc: Copy timestamps only when a frame is produced.
From: Pawel Osciak posc...@chromium.org
Timestamps for destination buffers are assigned by copying them from
corresponding source buffers when the decode operation results in a frame
being outputted to a destination buffer. But the decision when to do this, i.e.
whether the decode operation on current source buffer produced a destination
frame, is wrongly based on display status. Display status reflects the status
of the destination buffer, not source.
This used to work for firmwares version = 6, because in addition to the above,
we'd check the decoded frame type register, which was set to skipped if
a destination frame was not produced, exiting early from
s5p_mfc_handle_frame_new().
Firmware =7 does not set the frame type register for frames that were not
decoded anymore though, which results in us wrongly overwriting timestamps of
previously decoded buffers (firmware reports the same destination buffer address
as previously decoded one if a frame wasn't decoded during current operation).
To do it properly, we should be basing our decision to copy the timestamp on the
status of the source buffer, i.e. decode status. The decode status register
values are confusing, because in its case display means a frame has been
outputted to a destination buffer. We should copy if decode and display
is returned in it. This also works on = v6 firmware, which behaves in the same
way with regards to decode status register.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 66c1775..d636789 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -304,12 +304,15 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
{
struct s5p_mfc_dev *dev = ctx-dev;
unsigned int dst_frame_status;
+ unsigned int dec_frame_status;
struct s5p_mfc_buf *src_buf;
unsigned long flags;
unsigned int res_change;
dst_frame_status = s5p_mfc_hw_call(dev-mfc_ops, get_dspl_status, dev)
S5P_FIMV_DEC_STATUS_DECODING_STATUS_MASK;
+ dec_frame_status = s5p_mfc_hw_call(dev-mfc_ops, get_dec_status, dev)
+S5P_FIMV_DEC_STATUS_DECODING_STATUS_MASK;
res_change = (s5p_mfc_hw_call(dev-mfc_ops, get_dspl_status, dev)
S5P_FIMV_DEC_STATUS_RESOLUTION_MASK)
S5P_FIMV_DEC_STATUS_RESOLUTION_SHIFT;
@@ -342,8 +345,7 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
}
}
- if (dst_frame_status == S5P_FIMV_DEC_STATUS_DECODING_DISPLAY ||
- dst_frame_status == S5P_FIMV_DEC_STATUS_DECODING_ONLY)
+ if (dec_frame_status == S5P_FIMV_DEC_STATUS_DECODING_DISPLAY)
s5p_mfc_handle_frame_copy_time(ctx);
/* A frame has been decoded and is in the buffer */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Updated DVB-T tables - where to send them?
On 17 March 2014 23:44, Chris Rankin ranki...@yahoo.com wrote: Hi, The DVB-T initial tuning information for Crystal Palace in the UK is completely obsolete - despite my two attempts to submit an updated version over the YEARS. Where is the best place to send this information, please? Thanks, Chris I submitted updates for the whole of the UK in September. Check Crystal Palace here: http://git.linuxtv.org/dtv-scan-tables.git/blob_plain/HEAD:/dvb-t/uk-CrystalPalace You will probably find your distro hasn't updated. I did a pull request into this github repo https://github.com/oliv3r/dtv-scan-tables Si. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Updated DVB-T tables - where to send them?
Hi, Fedora 20 is using a new dvb-scan-tables package: * Mon Jan 13 2014 Till Maas opensou...@till.name - 0-4.20130713gitd913405 Unfortunately, it's still full of files dating from 2012! I will raise a bug in their bugzilla for them to ignore completely and then close when Fedora 22 is released. Cheers, Chris On Tuesday, 18 March 2014, 9:07, Simon Liddicott si...@liddicott.com wrote: I submitted updates for the whole of the UK in September. Check Crystal Palace here: http://git.linuxtv.org/dtv-scan-tables.git/blob_plain/HEAD:/dvb-t/uk-CrystalPalace You will probably find your distro hasn't updated. I did a pull request into this github repo https://github.com/oliv3r/dtv-scan-tables Si. On 17 March 2014 23:44, Chris Rankin ranki...@yahoo.com wrote: Hi, The DVB-T initial tuning information for Crystal Palace in the UK is completely obsolete - despite my two attempts to submit an updated version over the YEARS. Where is the best place to send this information, please? Thanks, Chris -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
On Tue, Mar 18, 2014 at 08:50:30AM +0100, Lothar Waßmann wrote: Hi, Laurent Pinchart wrote: Hi Lothar, On Monday 17 March 2014 16:14:36 Lothar Waßmann wrote: DE is not a clock signal, but an 'Enable' signal whose value (high or low) defines the window in which the pixel data is valid. The flag defines whether data is valid during the HIGH or LOW period of DE. The DRM_MODE_FLAG_POL_DE_(LOW|HIGH) do, by my impression of the proposed new DRM_MODE_FLAG_POL_DE_*EDGE flags is that they define sampling clock edges, not active levels. The current naming of the flags gives the impression that they describe the sampling edges of a clock signal. But the DE signal in fact is not a clock signal but a level sensitive gating signal. +1 -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 36/48] adv7604: Make output format configurable through pad format operations
Hi Laurent,
I've tested it and I thought I was going crazy. Everything was fine after
applying this patch, but as soon as I applied the next patch (37/48) the
colors were wrong. But that patch had nothing whatsoever to do with the
bus ordering. You managed to make a small but crucial bug and it was pure
bad luck that it ever worked.
See details below:
On 03/11/14 16:10, Laurent Pinchart wrote:
Replace the dummy video format operations by pad format operations that
configure the output format.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/i2c/adv7604.c | 280
include/media/adv7604.h | 56 -
2 files changed, 275 insertions(+), 61 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 851b350..5aa7c29 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -53,6 +53,28 @@ MODULE_LICENSE(GPL);
/* ADV7604 system clock frequency */
#define ADV7604_fsc (28636360)
+#define ADV7604_RGB_OUT (1 1)
+
+#define ADV7604_OP_FORMAT_SEL_8BIT (0 0)
+#define ADV7604_OP_FORMAT_SEL_10BIT (1 0)
+#define ADV7604_OP_FORMAT_SEL_12BIT (2 0)
+
+#define ADV7604_OP_MODE_SEL_SDR_422 (0 5)
+#define ADV7604_OP_MODE_SEL_DDR_422 (1 5)
+#define ADV7604_OP_MODE_SEL_SDR_444 (2 5)
+#define ADV7604_OP_MODE_SEL_DDR_444 (3 5)
+#define ADV7604_OP_MODE_SEL_SDR_422_2X (4 5)
+#define ADV7604_OP_MODE_SEL_ADI_CM (5 5)
+
+#define ADV7604_OP_CH_SEL_GBR(0 5)
+#define ADV7604_OP_CH_SEL_GRB(1 5)
+#define ADV7604_OP_CH_SEL_BGR(2 5)
+#define ADV7604_OP_CH_SEL_RGB(3 5)
+#define ADV7604_OP_CH_SEL_BRG(4 5)
+#define ADV7604_OP_CH_SEL_RBG(5 5)
Note that these values are shifted 5 bits to the left...
+
+#define ADV7604_OP_SWAP_CB_CR(1 0)
+
enum adv7604_type {
ADV7604,
ADV7611,
@@ -63,6 +85,14 @@ struct adv7604_reg_seq {
u8 val;
};
+struct adv7604_format_info {
+ enum v4l2_mbus_pixelcode code;
+ u8 op_ch_sel;
+ bool rgb_out;
+ bool swap_cb_cr;
+ u8 op_format_sel;
+};
+
struct adv7604_chip_info {
enum adv7604_type type;
@@ -78,6 +108,9 @@ struct adv7604_chip_info {
unsigned int tdms_lock_mask;
unsigned int fmt_change_digital_mask;
+ const struct adv7604_format_info *formats;
+ unsigned int nformats;
+
void (*set_termination)(struct v4l2_subdev *sd, bool enable);
void (*setup_irqs)(struct v4l2_subdev *sd);
unsigned int (*read_hdmi_pixelclock)(struct v4l2_subdev *sd);
@@ -101,12 +134,18 @@ struct adv7604_chip_info {
struct adv7604_state {
const struct adv7604_chip_info *info;
struct adv7604_platform_data pdata;
+
struct v4l2_subdev sd;
struct media_pad pads[ADV7604_PAD_MAX];
unsigned int source_pad;
+
struct v4l2_ctrl_handler hdl;
+
enum adv7604_pad selected_input;
+
struct v4l2_dv_timings timings;
+ const struct adv7604_format_info *format;
+
struct {
u8 edid[256];
u32 present;
@@ -771,6 +810,93 @@ static void adv7604_write_reg_seq(struct v4l2_subdev *sd,
adv7604_write_reg(sd, reg_seq[i].reg, reg_seq[i].val);
}
+/*
-
+ * Format helpers
+ */
+
+static const struct adv7604_format_info adv7604_formats[] = {
+ { V4L2_MBUS_FMT_RGB888_1X24, ADV7604_OP_CH_SEL_RGB, true, false,
+ ADV7604_OP_MODE_SEL_SDR_444 | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_YUYV8_2X8, ADV7604_OP_CH_SEL_RGB, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_YVYU8_2X8, ADV7604_OP_CH_SEL_RGB, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_YUYV10_2X10, ADV7604_OP_CH_SEL_RGB, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_10BIT },
+ { V4L2_MBUS_FMT_YVYU10_2X10, ADV7604_OP_CH_SEL_RGB, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_10BIT },
+ { V4L2_MBUS_FMT_YUYV12_2X12, ADV7604_OP_CH_SEL_RGB, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_12BIT },
+ { V4L2_MBUS_FMT_YVYU12_2X12, ADV7604_OP_CH_SEL_RGB, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_12BIT },
+ { V4L2_MBUS_FMT_UYVY8_1X16, ADV7604_OP_CH_SEL_RBG, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_8BIT
Re: [PATCH v8 3/10] Documentation: devicetree: Update Samsung FIMC DT binding
On Tue, Mar 11, 2014 at 04:34:30PM +, Sylwester Nawrocki wrote:
This patch documents following updates of the Exynos4 SoC camera subsystem
devicetree binding:
- addition of #clock-cells and clock-output-names properties to 'camera'
node - these are now needed so the image sensor sub-devices can reference
clocks provided by the camera host interface,
- dropped a note about required clock-frequency properties at the
image sensor nodes; the sensor devices can now control their clock
explicitly through the clk API and there is no need to require this
property in the camera host interface binding.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
---
Changes since v7:
- dropped a note about clock-frequency property in sensor nodes.
Changes since v6:
- #clock-cells, clock-output-names documented as mandatory properties;
- renamed cam_mclk_{a,b} to cam_{a,b}_clkout in the example dts,
this now matches changes in exynos4.dtsi further in the patch series;
- marked samsung,camclk-out property as deprecated.
Changes since v5:
- none.
Changes since v4:
- dropped a requirement of specific order of values in clocks/
clock-names properties (Mark) and reference to clock-names in
clock-output-names property description (Mark).
---
.../devicetree/bindings/media/samsung-fimc.txt | 44
+---
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt
b/Documentation/devicetree/bindings/media/samsung-fimc.txt
index 96312f6..922d6f8 100644
--- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
+++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
@@ -15,11 +15,21 @@ Common 'camera' node
Required properties:
-- compatible : must be samsung,fimc, simple-bus
While it was already the case, why is samsung,fimc also a simple bus?
If it has any properties which are required for the correct use of the
child nodes, it is _not_ a simple-bus.
-- clocks : list of clock specifiers, corresponding to entries in
- the clock-names property;
-- clock-names: must contain sclk_cam0, sclk_cam1, pxl_async0,
- pxl_async1 entries, matching entries in the clocks property.
+- compatible: must be samsung,fimc, simple-bus
+- clocks: list of clock specifiers, corresponding to entries in
+ the clock-names property;
+- clock-names : must contain sclk_cam0, sclk_cam1, pxl_async0,
+ pxl_async1 entries, matching entries in the clocks property.
+
+- #clock-cells: from the common clock bindings (../clock/clock-bindings.txt),
+ must be 1. A clock provider is associated with the 'camera' node and it
should
+ be referenced by external sensors that use clocks provided by the SoC on
+ CAM_*_CLKOUT pins. The clock specifier cell stores an index of a clock.
+ The indices are 0, 1 for CAM_A_CLKOUT, CAM_B_CLKOUT clocks respectively.
+
+- clock-output-names: from the common clock bindings, should contain names of
+ clocks registered by the camera subsystem corresponding to CAM_A_CLKOUT,
+ CAM_B_CLKOUT output clocks respectively.
And if we're adding more stuff required by child nodes it's definitely
not a simple-bus.
Get rid of simple-bus. Get the driver for samsung,fimc to probe its
children once it has set up.
Apologies for the late reply, and sorry to have to be negative on this.
Thanks,
Mark.
The pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt must be used
to define a required pinctrl state named default and optional pinctrl
states:
@@ -32,6 +42,7 @@ way around.
The 'camera' node must include at least one 'fimc' child node.
+
'fimc' device nodes
---
@@ -88,8 +99,8 @@ port nodes specifies data input - 0, 1 indicates input A, B
respectively.
Optional properties
-- samsung,camclk-out : specifies clock output for remote sensor,
-0 - CAM_A_CLKOUT, 1 - CAM_B_CLKOUT;
+- samsung,camclk-out (deprecated) : specifies clock output for remote sensor,
+ 0 - CAM_A_CLKOUT, 1 - CAM_B_CLKOUT;
Image sensor nodes
--
@@ -97,8 +108,6 @@ Image sensor nodes
The sensor device nodes should be added to their control bus controller (e.g.
I2C0) nodes and linked to a port node in the csis or the parallel-ports node,
using the common video interfaces bindings, defined in video-interfaces.txt.
-The implementation of this bindings requires clock-frequency property to be
-present in the sensor device nodes.
Example:
@@ -114,7 +123,7 @@ Example:
vddio-supply = ...;
clock-frequency = 2400;
- clocks = ...;
+ clocks = camera 1;
clock-names = mclk;
port {
@@ -135,7 +144,7 @@ Example:
vddio-supply = ...;
clock-frequency = 2400;
Re: [PATCH 1/9] mm: Provide new get_vaddr_pfns() helper
On Mon 17-03-14 13:53:35, Dave Hansen wrote:
On 03/17/2014 12:49 PM, Jan Kara wrote:
+int get_vaddr_pfns(unsigned long start, int nr_pfns, int write, int force,
+ struct pinned_pfns *pfns)
+{
...
+ if (!(vma-vm_flags (VM_IO | VM_PFNMAP))) {
+ pfns-got_ref = 1;
+ pfns-is_pages = 1;
+ ret = get_user_pages(current, mm, start, nr_pfns, write, force,
+pfns_vector_pages(pfns), NULL);
+ goto out;
+ }
Have you given any thought to how this should deal with VM_MIXEDMAP
vmas? get_user_pages() will freak when it hits the !vm_normal_page()
test on the pfnmapped ones, and jump out. Shouldn't get_vaddr_pfns() be
able to handle those too?
It could and it doesn't seem as a big complication. Although none of the
converted drivers need this functionality, I guess it makes sense to
implement this to make the API more consistent. So I can have a look at it
for the next iteration.
Honza
--
Jan Kara j...@suse.cz
SUSE Labs, CR
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] bttv: Add support for PCI-8604PW
This patch adds support for the PCI-8604PW card equipped with four 878A.
It is unknown who the manufacturer of this card is and no drivers were
available during development of the patch. According to images found
online, the card is originally sold with Linux DVR software.
A CPLD on the card prevents the 878A from requesting access to the
bus until an initialization sequence has been issued via GPIOs. The
implemented sequence uses the minimum number of GPIOs needed to
successfully unlock bus access. As there are many more GPIOs connected
to the CPLD, it is very likely that some of the others have an influence
on the bus arbitration scheduling. This should be investigated further
in case of performance issues.
The tested card contains an EEPROM on one of the 878A, but it is
completely empty (i.e. contains only 0xff), so it is not possible
to detect the card.
Signed-off-by: Daniel Glöckner daniel...@gmx.net
Tested-by: Robert Longbottom rongb...@googlemail.com
---
drivers/media/pci/bt8xx/bttv-cards.c | 102 +++
drivers/media/pci/bt8xx/bttv.h | 1 +
2 files changed, 103 insertions(+)
diff --git a/drivers/media/pci/bt8xx/bttv-cards.c
b/drivers/media/pci/bt8xx/bttv-cards.c
index 6662b49..9f6a7fb 100644
--- a/drivers/media/pci/bt8xx/bttv-cards.c
+++ b/drivers/media/pci/bt8xx/bttv-cards.c
@@ -52,6 +52,7 @@ static void osprey_eeprom(struct bttv *btv, const u8 ee[256]);
static void modtec_eeprom(struct bttv *btv);
static void init_PXC200(struct bttv *btv);
static void init_RTV24(struct bttv *btv);
+static void init_PCI8604PW(struct bttv *btv);
static void rv605_muxsel(struct bttv *btv, unsigned int input);
static void eagle_muxsel(struct bttv *btv, unsigned int input);
@@ -2856,6 +2857,22 @@ struct tvcard bttv_tvcards[] = {
.tuner_addr = ADDR_UNSET,
},
+ /* card 0xa5-- */
+ [BTTV_BOARD_PCI_8604PW] = {
+ /* PCI-8604PW with special unlock sequence */
+ .name = PCI-8604PW,
+ .video_inputs = 2,
+ /* .audio_inputs= 0, */
+ .svhs = NO_SVHS,
+ /* The second input is available on CN4, if populated.
+* The other 5x2 header (CN2?) connects to the same inputs
+* as the on-board BNCs */
+ .muxsel = MUXSEL(2, 3),
+ .tuner_type = TUNER_ABSENT,
+ .no_msp34xx = 1,
+ .no_tda7432 = 1,
+ .pll= PLL_35,
+ },
};
static const unsigned int bttv_num_tvcards = ARRAY_SIZE(bttv_tvcards);
@@ -3290,6 +3307,9 @@ void bttv_init_card1(struct bttv *btv)
case BTTV_BOARD_ADLINK_RTV24:
init_RTV24( btv );
break;
+ case BTTV_BOARD_PCI_8604PW:
+ init_PCI8604PW(btv);
+ break;
}
if (!bttv_tvcards[btv-c.type].has_dvb)
@@ -4170,6 +4190,88 @@ init_RTV24 (struct bttv *btv)
/* --- */
+/*
+ * The PCI-8604PW contains a CPLD, probably an ispMACH 4A, that filters
+ * the PCI REQ signals comming from the four BT878 chips. After power
+ * up, the CPLD does not forward requests to the bus, which prevents
+ * the BT878 from fetching RISC instructions from memory. While the
+ * CPLD is connected to most of the GPIOs of PCI device 0xD, only
+ * five appear to play a role in unlocking the REQ signal. The following
+ * sequence has been determined by trial and error without access to the
+ * original driver.
+ *
+ * Eight GPIOs of device 0xC are provided on connector CN4 (4 in, 4 out).
+ * Devices 0xE and 0xF do not appear to have anything connected to their
+ * GPIOs.
+ *
+ * The correct GPIO_OUT_EN value might have some more bits set. It should
+ * be possible to derive it from a boundary scan of the CPLD. Its JTAG
+ * pins are routed to test points.
+ *
+ */
+/* --- */
+static void
+init_PCI8604PW(struct bttv *btv)
+{
+ int state;
+
+ if ((PCI_SLOT(btv-c.pci-devfn) ~3) != 0xC) {
+ pr_warn(This is not a PCI-8604PW\n);
+ return;
+ }
+
+ if (PCI_SLOT(btv-c.pci-devfn) != 0xD)
+ return;
+
+ btwrite(0x080002, BT848_GPIO_OUT_EN);
+
+ state = (btread(BT848_GPIO_DATA) 21) 7;
+
+ for (;;) {
+ switch (state) {
+ case 1:
+ case 5:
+ case 6:
+ case 4:
+ pr_debug(PCI-8604PW in state %i, toggling pin\n,
+state);
+ btwrite(0x08, BT848_GPIO_DATA);
+ msleep(1);
+ btwrite(0x00, BT848_GPIO_DATA);
+ msleep(1);
+ break;
+ case 7:
+
[PATCH] v4l: ti-vpe: fix devm_ioremap_resource() return value checking
devm_ioremap_resource() returns a pointer to the remapped memory or
an ERR_PTR() encoded error code on failure. Fix the checks inside
csc_create() and sc_create() accordingly.
Cc: Archit Taneja arc...@ti.com
Cc: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
Compile tested only.
drivers/media/platform/ti-vpe/csc.c |4 ++--
drivers/media/platform/ti-vpe/sc.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
Index: b/drivers/media/platform/ti-vpe/csc.c
===
--- a/drivers/media/platform/ti-vpe/csc.c 2014-03-14 16:45:25.848724010
+0100
+++ b/drivers/media/platform/ti-vpe/csc.c 2014-03-18 11:01:36.595182833
+0100
@@ -187,9 +187,9 @@ struct csc_data *csc_create(struct platf
}
csc-base = devm_ioremap_resource(pdev-dev, csc-res);
- if (!csc-base) {
+ if (IS_ERR(csc-base)) {
dev_err(pdev-dev, failed to ioremap\n);
- return ERR_PTR(-ENOMEM);
+ return csc-base;
}
return csc;
Index: b/drivers/media/platform/ti-vpe/sc.c
===
--- a/drivers/media/platform/ti-vpe/sc.c2014-03-14 16:45:25.848724010
+0100
+++ b/drivers/media/platform/ti-vpe/sc.c2014-03-18 11:02:09.555182273
+0100
@@ -302,9 +302,9 @@ struct sc_data *sc_create(struct platfor
}
sc-base = devm_ioremap_resource(pdev-dev, sc-res);
- if (!sc-base) {
+ if (IS_ERR(sc-base)) {
dev_err(pdev-dev, failed to ioremap\n);
- return ERR_PTR(-ENOMEM);
+ return sc-base;
}
return sc;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 05/10] V4L: s5c73m3: Add device tree support
On 18/03/14 11:05, Arnd Bergmann wrote:
On Thursday 06 March 2014, Sylwester Nawrocki wrote:
This patch adds the V4L2 asynchronous subdev registration and
device tree support. Common clock API is used to control the
sensor master clock from within the subdev.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
This driver is in linux-next now, but
+node_ep = v4l2_of_get_next_endpoint(node, NULL);
+if (!node_ep) {
+dev_warn(dev, no endpoint defined for node: %s\n,
+node-full_name);
+return 0;
}
This function is not defined here, leading to build errors.
*sigh* it seems this [1] patch series ended up somehow in -next,
but it shouldn't. Mauro, could you please remove the 'exynos'
branch from media-next tree ? This should fix the problem.
Even though I have been trying to merge this patch to mainline
for ages, I'm ready to resign from it for now, not to add to
the mess we are already seeing [2].
[1] https://lkml.org/lkml/2014/3/6/352
[2] https://lkml.org/lkml/2014/3/17/547
Thanks,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] [media] atmel-isi: add v4l2 async probe support
Signed-off-by: Josh Wu josh...@atmel.com
---
drivers/media/platform/soc_camera/atmel-isi.c |5 +
include/media/atmel-isi.h |4
2 files changed, 9 insertions(+)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index f0b6c90..d22aba1 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -982,6 +982,11 @@ static int atmel_isi_probe(struct platform_device *pdev)
soc_host-v4l2_dev.dev = pdev-dev;
soc_host-nr= pdev-id;
+ if (isi-pdata.asd_sizes) {
+ soc_host-asd = isi-pdata.asd;
+ soc_host-asd_sizes = isi-pdata.asd_sizes;
+ }
+
ret = soc_camera_host_register(soc_host);
if (ret) {
dev_err(pdev-dev, Unable to register soc camera host\n);
diff --git a/include/media/atmel-isi.h b/include/media/atmel-isi.h
index 2b02347..c2e5703 100644
--- a/include/media/atmel-isi.h
+++ b/include/media/atmel-isi.h
@@ -106,6 +106,8 @@
#define ISI_DATAWIDTH_80x01
#define ISI_DATAWIDTH_10 0x02
+struct v4l2_async_subdev;
+
struct isi_platform_data {
u8 has_emb_sync;
u8 emb_crc_sync;
@@ -118,6 +120,8 @@ struct isi_platform_data {
u32 frate;
/* Using for ISI_MCK */
u32 mck_hz;
+ struct v4l2_async_subdev **asd; /* Flat array, arranged in groups */
+ int *asd_sizes; /* 0-terminated array of asd group sizes */
};
#endif /* __ATMEL_ISI_H__ */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] [media] atmel-isi: convert the pdata from pointer to structure
Now the platform data is initialized by allocation of isi
structure. In the future, we use pdata to store the dt parameters.
Signed-off-by: Josh Wu josh...@atmel.com
---
drivers/media/platform/soc_camera/atmel-isi.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index d22aba1..93bf1cb 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -84,7 +84,7 @@ struct atmel_isi {
struct clk *mck;
unsigned intirq;
- struct isi_platform_data*pdata;
+ struct isi_platform_datapdata;
u16 width_flags;/* max 12 bits */
struct list_headvideo_buffer_list;
@@ -350,7 +350,7 @@ static void start_dma(struct atmel_isi *isi, struct
frame_buffer *buffer)
cfg1 = ~ISI_CFG1_FRATE_DIV_MASK;
/* Enable linked list */
- cfg1 |= isi-pdata-frate | ISI_CFG1_DISCR;
+ cfg1 |= isi-pdata.frate | ISI_CFG1_DISCR;
/* Enable codec path and ISI */
ctrl = ISI_CTRL_CDC | ISI_CTRL_EN;
@@ -797,7 +797,7 @@ static int isi_camera_set_bus_param(struct
soc_camera_device *icd)
/* Make choises, based on platform preferences */
if ((common_flags V4L2_MBUS_HSYNC_ACTIVE_HIGH)
(common_flags V4L2_MBUS_HSYNC_ACTIVE_LOW)) {
- if (isi-pdata-hsync_act_low)
+ if (isi-pdata.hsync_act_low)
common_flags = ~V4L2_MBUS_HSYNC_ACTIVE_HIGH;
else
common_flags = ~V4L2_MBUS_HSYNC_ACTIVE_LOW;
@@ -805,7 +805,7 @@ static int isi_camera_set_bus_param(struct
soc_camera_device *icd)
if ((common_flags V4L2_MBUS_VSYNC_ACTIVE_HIGH)
(common_flags V4L2_MBUS_VSYNC_ACTIVE_LOW)) {
- if (isi-pdata-vsync_act_low)
+ if (isi-pdata.vsync_act_low)
common_flags = ~V4L2_MBUS_VSYNC_ACTIVE_HIGH;
else
common_flags = ~V4L2_MBUS_VSYNC_ACTIVE_LOW;
@@ -813,7 +813,7 @@ static int isi_camera_set_bus_param(struct
soc_camera_device *icd)
if ((common_flags V4L2_MBUS_PCLK_SAMPLE_RISING)
(common_flags V4L2_MBUS_PCLK_SAMPLE_FALLING)) {
- if (isi-pdata-pclk_act_falling)
+ if (isi-pdata.pclk_act_falling)
common_flags = ~V4L2_MBUS_PCLK_SAMPLE_RISING;
else
common_flags = ~V4L2_MBUS_PCLK_SAMPLE_FALLING;
@@ -835,9 +835,9 @@ static int isi_camera_set_bus_param(struct
soc_camera_device *icd)
if (common_flags V4L2_MBUS_PCLK_SAMPLE_FALLING)
cfg1 |= ISI_CFG1_PIXCLK_POL_ACTIVE_FALLING;
- if (isi-pdata-has_emb_sync)
+ if (isi-pdata.has_emb_sync)
cfg1 |= ISI_CFG1_EMB_SYNC;
- if (isi-pdata-full_mode)
+ if (isi-pdata.full_mode)
cfg1 |= ISI_CFG1_FULL_MODE;
isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
@@ -905,7 +905,7 @@ static int atmel_isi_probe(struct platform_device *pdev)
if (IS_ERR(isi-pclk))
return PTR_ERR(isi-pclk);
- isi-pdata = pdata;
+ memcpy(isi-pdata, pdata, sizeof(struct isi_platform_data));
isi-active = NULL;
spin_lock_init(isi-lock);
INIT_LIST_HEAD(isi-video_buffer_list);
@@ -921,7 +921,7 @@ static int atmel_isi_probe(struct platform_device *pdev)
/* Set ISI_MCK's frequency, it should be faster than pixel
* clock.
*/
- ret = clk_set_rate(isi-mck, pdata-mck_hz);
+ ret = clk_set_rate(isi-mck, isi-pdata.mck_hz);
if (ret 0)
return ret;
}
@@ -955,9 +955,9 @@ static int atmel_isi_probe(struct platform_device *pdev)
goto err_ioremap;
}
- if (pdata-data_width_flags ISI_DATAWIDTH_8)
+ if (isi-pdata.data_width_flags ISI_DATAWIDTH_8)
isi-width_flags = 1 7;
- if (pdata-data_width_flags ISI_DATAWIDTH_10)
+ if (isi-pdata.data_width_flags ISI_DATAWIDTH_10)
isi-width_flags |= 1 9;
isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] [media] atmel-isi: Add DT support for Atmel ISI driver
This patch series add DT support for atmel ISI driver. It can support the common v4l2 DT interfaces. Josh Wu (3): [media] atmel-isi: add v4l2 async probe support [media] atmel-isi: convert the pdata from pointer to structure [media] atmel-isi: add primary DT support .../devicetree/bindings/media/atmel-isi.txt| 51 + drivers/media/platform/soc_camera/atmel-isi.c | 58 include/media/atmel-isi.h |4 ++ 3 files changed, 101 insertions(+), 12 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/atmel-isi.txt -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] [media] atmel-isi: add primary DT support
This patch add the DT support for Atmel ISI driver.
It use the same v4l2 DT interface that defined in video-interfaces.txt.
Signed-off-by: Josh Wu josh...@atmel.com
Cc: devicet...@vger.kernel.org
---
.../devicetree/bindings/media/atmel-isi.txt| 51
drivers/media/platform/soc_camera/atmel-isi.c | 33 -
2 files changed, 82 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/atmel-isi.txt
diff --git a/Documentation/devicetree/bindings/media/atmel-isi.txt
b/Documentation/devicetree/bindings/media/atmel-isi.txt
new file mode 100644
index 000..07f00eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/atmel-isi.txt
@@ -0,0 +1,51 @@
+Atmel Image Sensor Interface (ISI) SoC Camera Subsystem
+--
+
+Required properties:
+- compatible: must be atmel,at91sam9g45-isi
+- reg: physical base address and length of the registers set for the device;
+- interrupts: should contain IRQ line for the ISI;
+- clocks: list of clock specifiers, corresponding to entries in
+ the clock-names property;
+- clock-names: must contain isi_clk, which is the isi peripherial clock.
+ isi_mck is optinal, it is the master clock output to sensor.
+
+Optional properties:
+- atmel,isi-disable-preview: a boolean property to disable the preview channel;
+
+Example:
+ isi: isi@f0034000 {
+ compatible = atmel,at91sam9g45-isi;
+ reg = 0xf0034000 0x4000;
+ interrupts = 37 IRQ_TYPE_LEVEL_HIGH 5;
+
+ clocks = isi_clk, pck1;
+ clock-names = isi_clk, isi_mck;
+
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_isi pinctrl_pck1_as_isi_mck;
+
+ port {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ isi_0: endpoint {
+ remote-endpoint = ov2640_0;
+ };
+ };
+ };
+
+ i2c1: i2c@f0018000 {
+ ov2640: camera@0x30 {
+ compatible = omnivision,ov2640;
+ reg = 0x30;
+
+ port {
+ ov2640_0: endpoint {
+ remote-endpoint = isi_0;
+ bus-width = 8;
+ };
+ };
+ };
+ };
+
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index 93bf1cb..1822129 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -19,6 +19,7 @@
#include linux/interrupt.h
#include linux/kernel.h
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/slab.h
@@ -33,6 +34,7 @@
#define VID_LIMIT_BYTES(16 * 1024 * 1024)
#define MIN_FRAME_RATE 15
#define FRAME_INTERVAL_MILLI_SEC (1000 / MIN_FRAME_RATE)
+#define ISI_DEFAULT_MCLK_FREQ 2500
/* Frame buffer descriptor */
struct fbd {
@@ -878,6 +880,22 @@ static int atmel_isi_remove(struct platform_device *pdev)
return 0;
}
+static int atmel_isi_probe_dt(struct atmel_isi *isi,
+ struct platform_device *pdev)
+{
+ struct device_node *node = pdev-dev.of_node;
+
+ isi-pdata.full_mode = !of_property_read_bool(node,
+ atmel,isi-disable-preview);
+
+ /* Default settings for ISI */
+ isi-pdata.mck_hz = ISI_DEFAULT_MCLK_FREQ;
+ isi-pdata.frate = ISI_CFG1_FRATE_CAPTURE_ALL;
+ isi-pdata.data_width_flags = ISI_DATAWIDTH_8 | ISI_DATAWIDTH_10;
+
+ return 0;
+}
+
static int atmel_isi_probe(struct platform_device *pdev)
{
unsigned int irq;
@@ -889,7 +907,7 @@ static int atmel_isi_probe(struct platform_device *pdev)
struct isi_platform_data *pdata;
pdata = dev-platform_data;
- if (!pdata || !pdata-data_width_flags) {
+ if ((!pdata || !pdata-data_width_flags) !pdev-dev.of_node) {
dev_err(pdev-dev,
No config available for Atmel ISI\n);
return -EINVAL;
@@ -905,7 +923,11 @@ static int atmel_isi_probe(struct platform_device *pdev)
if (IS_ERR(isi-pclk))
return PTR_ERR(isi-pclk);
- memcpy(isi-pdata, pdata, sizeof(struct isi_platform_data));
+ if (pdata)
+ memcpy(isi-pdata, pdata, sizeof(struct isi_platform_data));
+ else/* dt probe */
+ atmel_isi_probe_dt(isi, pdev);
+
isi-active = NULL;
spin_lock_init(isi-lock);
INIT_LIST_HEAD(isi-video_buffer_list);
@@ -1007,11 +1029,18 @@ err_alloc_ctx:
return ret;
}
+static const struct of_device_id atmel_isi_of_match[] = {
+ { .compatible =
Re: [PATCH v8 3/10] Documentation: devicetree: Update Samsung FIMC DT binding
Hi Mark,
Thanks for your review.
On 18/03/14 11:02, Mark Rutland wrote:
On Tue, Mar 11, 2014 at 04:34:30PM +, Sylwester Nawrocki wrote:
This patch documents following updates of the Exynos4 SoC camera subsystem
devicetree binding:
- addition of #clock-cells and clock-output-names properties to 'camera'
node - these are now needed so the image sensor sub-devices can
reference
clocks provided by the camera host interface,
- dropped a note about required clock-frequency properties at the
image sensor nodes; the sensor devices can now control their clock
explicitly through the clk API and there is no need to require this
property in the camera host interface binding.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
---
Changes since v7:
- dropped a note about clock-frequency property in sensor nodes.
Changes since v6:
- #clock-cells, clock-output-names documented as mandatory properties;
- renamed cam_mclk_{a,b} to cam_{a,b}_clkout in the example dts,
this now matches changes in exynos4.dtsi further in the patch series;
- marked samsung,camclk-out property as deprecated.
Changes since v5:
- none.
Changes since v4:
- dropped a requirement of specific order of values in clocks/
clock-names properties (Mark) and reference to clock-names in
clock-output-names property description (Mark).
---
.../devicetree/bindings/media/samsung-fimc.txt | 44
+---
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt
b/Documentation/devicetree/bindings/media/samsung-fimc.txt
index 96312f6..922d6f8 100644
--- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
+++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
@@ -15,11 +15,21 @@ Common 'camera' node
Required properties:
-- compatible : must be samsung,fimc, simple-bus
While it was already the case, why is samsung,fimc also a simple bus?
IIRC the main reason was to have children automatically instantiated
in Linux, also samsung,fimc is a master node gathering the all related
camera subsystem memory mapped IP blocks.
If it has any properties which are required for the correct use of the
child nodes, it is _not_ a simple-bus.
Then this can be considered a separate issue, and could be addressed
in a separate patch ?
-- clocks : list of clock specifiers, corresponding to entries in
-the clock-names property;
-- clock-names : must contain sclk_cam0, sclk_cam1, pxl_async0,
-pxl_async1 entries, matching entries in the clocks property.
+- compatible: must be samsung,fimc, simple-bus
+- clocks: list of clock specifiers, corresponding to entries in
+ the clock-names property;
+- clock-names : must contain sclk_cam0, sclk_cam1, pxl_async0,
+ pxl_async1 entries, matching entries in the clocks property.
+
+- #clock-cells: from the common clock bindings
(../clock/clock-bindings.txt),
+ must be 1. A clock provider is associated with the 'camera' node and it
should
+ be referenced by external sensors that use clocks provided by the SoC on
+ CAM_*_CLKOUT pins. The clock specifier cell stores an index of a clock.
+ The indices are 0, 1 for CAM_A_CLKOUT, CAM_B_CLKOUT clocks respectively.
+
+- clock-output-names: from the common clock bindings, should contain
names of
+ clocks registered by the camera subsystem corresponding to CAM_A_CLKOUT,
+ CAM_B_CLKOUT output clocks respectively.
And if we're adding more stuff required by child nodes it's definitely
not a simple-bus.
Get rid of simple-bus. Get the driver for samsung,fimc to probe its
children once it has set up.
Apologies for the late reply, and sorry to have to be negative on this.
While I agree with you that the simple-bus might not be a best idea,
I can't see how your suggestion could be now implemented in Linux, since
AFAIK there is no API like of_platform_unpopulate(), so device objects
can be removed upon the driver module removal.
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
Hi Lothar,
On Tuesday 18 March 2014 08:50:30 Lothar Waßmann wrote:
Laurent Pinchart wrote:
On Monday 17 March 2014 16:14:36 Lothar Waßmann wrote:
Laurent Pinchart wrote:
On Monday 17 March 2014 14:41:09 Andrzej Hajda wrote:
On 03/13/2014 06:17 PM, Denis Carikli wrote:
We need a way to pass signal polarity informations
between DRM panels, and the display drivers.
To do that, a pol_flags field was added to drm_display_mode.
Signed-off-by: Denis Carikli de...@eukrea.com
---
ChangeLog v10-v11:
- Since the imx-drm won't be able to retrive its regulators
from the device tree when using display-timings nodes,
and that I was told that the drm simple-panel driver
already supported that, I then, instead, added what was
lacking to make the eukrea displays work with the
drm-simple-panel driver.
That required a way to get back the display polarity
informations from the imx-drm driver without affecting
userspace.
---
include/drm/drm_crtc.h |8
1 file changed, 8 insertions(+)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f764654..61a4fe1 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -131,6 +131,13 @@ enum drm_mode_status {
#define DRM_MODE_FLAG_3D_MAX
DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
+#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE BIT(1)
+#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGE BIT(2)
+#define DRM_MODE_FLAG_POL_PIXDATA_PRESERVE BIT(3)
+#define DRM_MODE_FLAG_POL_DE_NEGEDGE BIT(4)
+#define DRM_MODE_FLAG_POL_DE_POSEDGE BIT(5)
+#define DRM_MODE_FLAG_POL_DE_PRESERVE BIT(6)
Could you add some description to these flags.
What are *_PRESERVE flags for?
Are those flags 1:1 compatible with respective 'videomode:flags'?
I guess DE flags should be rather DRM_MODE_FLAG_POL_DE_(LOW|HIGH),
am I right?
Possibly nitpicking, I wouldn't call the clock edge on which data
signals are generated/sampled data polarity. This is clock polarity
information.
Have you seen cases where pixel data and DE are geenrated or need to
be sampled on different edges ?
DE is not a clock signal, but an 'Enable' signal whose value (high or
low) defines the window in which the pixel data is valid.
The flag defines whether data is valid during the HIGH or LOW period of
DE.
The DRM_MODE_FLAG_POL_DE_(LOW|HIGH) do, by my impression of the proposed
new DRM_MODE_FLAG_POL_DE_*EDGE flags is that they define sampling clock
edges, not active levels.
The current naming of the flags gives the impression that they describe
the sampling edges of a clock signal. But the DE signal in fact is not
a clock signal but a level sensitive gating signal.
That's not my point. I *know* that DE is a data gating signal with a polarity
already defined by the DRM_MODE_FLAG_POL_DE_(LOW|HIGH) flags. Like all other
signals it gets generated on a clock edge and is sampled on a clock edge. The
DRM_MODE_FLAG_POL_DE_*EDGE flags proposed above describe seem to describe just
that, *not* the signal polarity. I thus want to know whether there are systems
where the data signals and the DE signal need to be sampled on different edges
of the pixel clock.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
On Tue, Mar 18, 2014 at 01:41:54PM +0100, Laurent Pinchart wrote: Hi Lothar, That's not my point. I *know* that DE is a data gating signal with a polarity already defined by the DRM_MODE_FLAG_POL_DE_(LOW|HIGH) flags. Like all other signals it gets generated on a clock edge and is sampled on a clock edge. The DRM_MODE_FLAG_POL_DE_*EDGE flags proposed above describe seem to describe just that, *not* the signal polarity. I thus want to know whether there are systems where the data signals and the DE signal need to be sampled on different edges of the pixel clock. That's not relevant to this patch series though. This patch series is about adding configuration which will allow iMX6 SoCs to be properly configured for their displays. iMX has the ability to: - define the polarity of the clock signal - define the polarity of the other signals It does not have the ability to define which clock edge individual signals like vsync (frame clock), hsync (line clock), disable enable change on independently. So, it doesn't make sense _here_ for the display enable to be defined by an edge - it's not something that can be changed here. What can only be changed is it's active level. Of course, there may be some which can do this, and that's a separate problem that would need to be addressed when there's hardware that does support it. The objection which Lothar is raising is that _this_ definition does not match the _hardware_ capabilities which it is intended to be used with, which is a very valid objection. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 36/48] adv7604: Make output format configurable through pad format operations
Replace the dummy video format operations by pad format operations that
configure the output format.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/i2c/adv7604.c | 280
include/media/adv7604.h | 56 -
2 files changed, 275 insertions(+), 61 deletions(-)
Changes since v3:
- Shift op_ch_sel in adv7604_op_ch_sel()
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 79fb34d..59f7bf0 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -53,6 +53,28 @@ MODULE_LICENSE(GPL);
/* ADV7604 system clock frequency */
#define ADV7604_fsc (28636360)
+#define ADV7604_RGB_OUT(1 1)
+
+#define ADV7604_OP_FORMAT_SEL_8BIT (0 0)
+#define ADV7604_OP_FORMAT_SEL_10BIT(1 0)
+#define ADV7604_OP_FORMAT_SEL_12BIT(2 0)
+
+#define ADV7604_OP_MODE_SEL_SDR_422(0 5)
+#define ADV7604_OP_MODE_SEL_DDR_422(1 5)
+#define ADV7604_OP_MODE_SEL_SDR_444(2 5)
+#define ADV7604_OP_MODE_SEL_DDR_444(3 5)
+#define ADV7604_OP_MODE_SEL_SDR_422_2X (4 5)
+#define ADV7604_OP_MODE_SEL_ADI_CM (5 5)
+
+#define ADV7604_OP_CH_SEL_GBR (0 5)
+#define ADV7604_OP_CH_SEL_GRB (1 5)
+#define ADV7604_OP_CH_SEL_BGR (2 5)
+#define ADV7604_OP_CH_SEL_RGB (3 5)
+#define ADV7604_OP_CH_SEL_BRG (4 5)
+#define ADV7604_OP_CH_SEL_RBG (5 5)
+
+#define ADV7604_OP_SWAP_CB_CR (1 0)
+
enum adv7604_type {
ADV7604,
ADV7611,
@@ -63,6 +85,14 @@ struct adv7604_reg_seq {
u8 val;
};
+struct adv7604_format_info {
+ enum v4l2_mbus_pixelcode code;
+ u8 op_ch_sel;
+ bool rgb_out;
+ bool swap_cb_cr;
+ u8 op_format_sel;
+};
+
struct adv7604_chip_info {
enum adv7604_type type;
@@ -78,6 +108,9 @@ struct adv7604_chip_info {
unsigned int tdms_lock_mask;
unsigned int fmt_change_digital_mask;
+ const struct adv7604_format_info *formats;
+ unsigned int nformats;
+
void (*set_termination)(struct v4l2_subdev *sd, bool enable);
void (*setup_irqs)(struct v4l2_subdev *sd);
unsigned int (*read_hdmi_pixelclock)(struct v4l2_subdev *sd);
@@ -101,12 +134,18 @@ struct adv7604_chip_info {
struct adv7604_state {
const struct adv7604_chip_info *info;
struct adv7604_platform_data pdata;
+
struct v4l2_subdev sd;
struct media_pad pads[ADV7604_PAD_MAX];
unsigned int source_pad;
+
struct v4l2_ctrl_handler hdl;
+
enum adv7604_pad selected_input;
+
struct v4l2_dv_timings timings;
+ const struct adv7604_format_info *format;
+
struct {
u8 edid[256];
u32 present;
@@ -771,6 +810,93 @@ static void adv7604_write_reg_seq(struct v4l2_subdev *sd,
adv7604_write_reg(sd, reg_seq[i].reg, reg_seq[i].val);
}
+/*
-
+ * Format helpers
+ */
+
+static const struct adv7604_format_info adv7604_formats[] = {
+ { V4L2_MBUS_FMT_RGB888_1X24, ADV7604_OP_CH_SEL_RGB, true, false,
+ ADV7604_OP_MODE_SEL_SDR_444 | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_YUYV8_2X8, ADV7604_OP_CH_SEL_RGB, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_YVYU8_2X8, ADV7604_OP_CH_SEL_RGB, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_YUYV10_2X10, ADV7604_OP_CH_SEL_RGB, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_10BIT },
+ { V4L2_MBUS_FMT_YVYU10_2X10, ADV7604_OP_CH_SEL_RGB, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_10BIT },
+ { V4L2_MBUS_FMT_YUYV12_2X12, ADV7604_OP_CH_SEL_RGB, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_12BIT },
+ { V4L2_MBUS_FMT_YVYU12_2X12, ADV7604_OP_CH_SEL_RGB, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_12BIT },
+ { V4L2_MBUS_FMT_UYVY8_1X16, ADV7604_OP_CH_SEL_RBG, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_VYUY8_1X16, ADV7604_OP_CH_SEL_RBG, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_YUYV8_1X16, ADV7604_OP_CH_SEL_RGB, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_YVYU8_1X16, ADV7604_OP_CH_SEL_RGB, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_8BIT },
+ {
Re: [PATCH v3 36/48] adv7604: Make output format configurable through pad format operations
Hi Hans,
On Tuesday 18 March 2014 10:32:32 Hans Verkuil wrote:
Hi Laurent,
I've tested it and I thought I was going crazy. Everything was fine after
applying this patch, but as soon as I applied the next patch (37/48) the
colors were wrong. But that patch had nothing whatsoever to do with the
bus ordering. You managed to make a small but crucial bug and it was pure
bad luck that it ever worked.
See details below:
On 03/11/14 16:10, Laurent Pinchart wrote:
Replace the dummy video format operations by pad format operations that
configure the output format.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/i2c/adv7604.c | 280 +++
include/media/adv7604.h | 56 -
2 files changed, 275 insertions(+), 61 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 851b350..5aa7c29 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -53,6 +53,28 @@ MODULE_LICENSE(GPL);
/* ADV7604 system clock frequency */
#define ADV7604_fsc (28636360)
+#define ADV7604_RGB_OUT(1 1)
+
+#define ADV7604_OP_FORMAT_SEL_8BIT (0 0)
+#define ADV7604_OP_FORMAT_SEL_10BIT(1 0)
+#define ADV7604_OP_FORMAT_SEL_12BIT(2 0)
+
+#define ADV7604_OP_MODE_SEL_SDR_422(0 5)
+#define ADV7604_OP_MODE_SEL_DDR_422(1 5)
+#define ADV7604_OP_MODE_SEL_SDR_444(2 5)
+#define ADV7604_OP_MODE_SEL_DDR_444(3 5)
+#define ADV7604_OP_MODE_SEL_SDR_422_2X (4 5)
+#define ADV7604_OP_MODE_SEL_ADI_CM (5 5)
+
+#define ADV7604_OP_CH_SEL_GBR (0 5)
+#define ADV7604_OP_CH_SEL_GRB (1 5)
+#define ADV7604_OP_CH_SEL_BGR (2 5)
+#define ADV7604_OP_CH_SEL_RGB (3 5)
+#define ADV7604_OP_CH_SEL_BRG (4 5)
+#define ADV7604_OP_CH_SEL_RBG (5 5)
Note that these values are shifted 5 bits to the left...
[snip]
+struct adv7604_format_info {
+ enum v4l2_mbus_pixelcode code;
+ u8 op_ch_sel;
+ bool rgb_out;
+ bool swap_cb_cr;
+ u8 op_format_sel;
+};
[snip]
+static const struct adv7604_format_info adv7604_formats[] = {
+ { V4L2_MBUS_FMT_RGB888_1X24, ADV7604_OP_CH_SEL_RGB, true, false,
+ ADV7604_OP_MODE_SEL_SDR_444 | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_YUYV8_2X8, ADV7604_OP_CH_SEL_RGB, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_YVYU8_2X8, ADV7604_OP_CH_SEL_RGB, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_YUYV10_2X10, ADV7604_OP_CH_SEL_RGB, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_10BIT },
+ { V4L2_MBUS_FMT_YVYU10_2X10, ADV7604_OP_CH_SEL_RGB, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_10BIT },
+ { V4L2_MBUS_FMT_YUYV12_2X12, ADV7604_OP_CH_SEL_RGB, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_12BIT },
+ { V4L2_MBUS_FMT_YVYU12_2X12, ADV7604_OP_CH_SEL_RGB, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_12BIT },
+ { V4L2_MBUS_FMT_UYVY8_1X16, ADV7604_OP_CH_SEL_RBG, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_VYUY8_1X16, ADV7604_OP_CH_SEL_RBG, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_YUYV8_1X16, ADV7604_OP_CH_SEL_RGB, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_YVYU8_1X16, ADV7604_OP_CH_SEL_RGB, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_UYVY10_1X20, ADV7604_OP_CH_SEL_RBG, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_10BIT },
+ { V4L2_MBUS_FMT_VYUY10_1X20, ADV7604_OP_CH_SEL_RBG, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_10BIT },
+ { V4L2_MBUS_FMT_YUYV10_1X20, ADV7604_OP_CH_SEL_RGB, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_10BIT },
+ { V4L2_MBUS_FMT_YVYU10_1X20, ADV7604_OP_CH_SEL_RGB, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_10BIT },
+ { V4L2_MBUS_FMT_UYVY12_1X24, ADV7604_OP_CH_SEL_RBG, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_12BIT },
+ { V4L2_MBUS_FMT_VYUY12_1X24, ADV7604_OP_CH_SEL_RBG, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_12BIT },
+ { V4L2_MBUS_FMT_YUYV12_1X24,
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
Hi Russell, On Tuesday 18 March 2014 12:56:23 Russell King - ARM Linux wrote: On Tue, Mar 18, 2014 at 01:41:54PM +0100, Laurent Pinchart wrote: Hi Lothar, That's not my point. I *know* that DE is a data gating signal with a polarity already defined by the DRM_MODE_FLAG_POL_DE_(LOW|HIGH) flags. Like all other signals it gets generated on a clock edge and is sampled on a clock edge. The DRM_MODE_FLAG_POL_DE_*EDGE flags proposed above describe seem to describe just that, *not* the signal polarity. I thus want to know whether there are systems where the data signals and the DE signal need to be sampled on different edges of the pixel clock. That's not relevant to this patch series though. This patch series is about adding configuration which will allow iMX6 SoCs to be properly configured for their displays. iMX has the ability to: - define the polarity of the clock signal - define the polarity of the other signals It does not have the ability to define which clock edge individual signals like vsync (frame clock), hsync (line clock), disable enable change on independently. So, it doesn't make sense _here_ for the display enable to be defined by an edge - it's not something that can be changed here. What can only be changed is it's active level. Of course, there may be some which can do this, and that's a separate problem that would need to be addressed when there's hardware that does support it. The objection which Lothar is raising is that _this_ definition does not match the _hardware_ capabilities which it is intended to be used with, which is a very valid objection. Thank you for the clarification. That absolutely makes sense. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/12] imx-drm: Use drm_display_mode timings flags.
Hi,
Denis Carikli wrote:
The previous hardware behaviour was kept if the
flags are not set.
Signed-off-by: Denis Carikli de...@eukrea.com
---
ChangeLog v10-v11:
- This patch was splitted-out and adapted from:
Prepare imx-drm for extra display-timings retrival.
- The display-timings dt specific part was removed.
- The flags names were changed to use the DRM ones from:
drm: drm_display_mode: add signal polarity flags
---
drivers/staging/imx-drm/imx-drm-core.c | 10 ++
drivers/staging/imx-drm/imx-drm.h |6 ++
drivers/staging/imx-drm/imx-hdmi.c |3 +++
drivers/staging/imx-drm/imx-ldb.c |3 +++
drivers/staging/imx-drm/imx-tve.c |3 +++
drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h |6 --
drivers/staging/imx-drm/ipu-v3/ipu-di.c |7 ++-
drivers/staging/imx-drm/ipuv3-crtc.c| 21 +++--
3 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
index b95cba1..3abeea3 100644
--- a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
+++ b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
@@ -29,9 +29,11 @@ enum ipuv3_type {
#define CLK_POL_ACTIVE_LOW 0
#define CLK_POL_ACTIVE_HIGH 1
+#define CLK_POL_PRESERVE 2
#define ENABLE_POL_NEGEDGE 0
#define ENABLE_POL_POSEDGE 1
+#define ENABLE_POL_PRESERVE 2
/*
* Bitfield of Display Interface signal polarities.
@@ -43,10 +45,10 @@ struct ipu_di_signal_cfg {
unsigned clksel_en:1;
unsigned clkidle_en:1;
unsigned data_pol:1;/* true = inverted */
- unsigned clk_pol:1;
- unsigned enable_pol:1;
unsigned Hsync_pol:1; /* true = active high */
unsigned Vsync_pol:1;
+ u8 clk_pol;
+ u8 enable_pol;
u16 width;
u16 height;
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-di.c
b/drivers/staging/imx-drm/ipu-v3/ipu-di.c
index 53646aa..791080b 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-di.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-di.c
@@ -597,6 +597,8 @@ int ipu_di_init_sync_panel(struct ipu_di *di, struct
ipu_di_signal_cfg *sig)
if (sig-clk_pol == CLK_POL_ACTIVE_HIGH)
di_gen |= DI_GEN_POLARITY_DISP_CLK;
+ else if (sig-clk_pol == CLK_POL_ACTIVE_LOW)
+ di_gen = ~DI_GEN_POLARITY_DISP_CLK;
ipu_di_write(di, di_gen, DI_GENERAL);
@@ -604,10 +606,13 @@ int ipu_di_init_sync_panel(struct ipu_di *di, struct
ipu_di_signal_cfg *sig)
DI_SYNC_AS_GEN);
reg = ipu_di_read(di, DI_POL);
- reg = ~(DI_POL_DRDY_DATA_POLARITY | DI_POL_DRDY_POLARITY_15);
+ reg = ~(DI_POL_DRDY_DATA_POLARITY);
if (sig-enable_pol == ENABLE_POL_POSEDGE)
reg |= DI_POL_DRDY_POLARITY_15;
+ else if (sig-enable_pol == ENABLE_POL_NEGEDGE)
+ reg = ~DI_POL_DRDY_POLARITY_15;
+
if (sig-data_pol)
reg |= DI_POL_DRDY_DATA_POLARITY;
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c
b/drivers/staging/imx-drm/ipuv3-crtc.c
index 8cfeb47..c75034e 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -157,8 +157,25 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
if (mode-flags DRM_MODE_FLAG_PVSYNC)
sig_cfg.Vsync_pol = 1;
- sig_cfg.enable_pol = ENABLE_POL_POSEDGE;
- sig_cfg.clk_pol = CLK_POL_ACTIVE_LOW;
+ if (mode-pol_flags DRM_MODE_FLAG_POL_PIXDATA_POSEDGE)
+ sig_cfg.enable_pol = ENABLE_POL_POSEDGE;
+ else if (mode-pol_flags DRM_MODE_FLAG_POL_DE_NEGEDGE)
+ sig_cfg.enable_pol = ENABLE_POL_NEGEDGE;
+ else if (mode-pol_flags DRM_MODE_FLAG_POL_PIXDATA_PRESERVE)
+ sig_cfg.enable_pol = ENABLE_POL_PRESERVE;
+ else
+ sig_cfg.enable_pol = ENABLE_POL_POSEDGE;
+
+ if (mode-private_flags DRM_MODE_FLAG_POL_DE_POSEDGE)
+ sig_cfg.clk_pol = CLK_POL_ACTIVE_HIGH;
+ else if (mode-private_flags DRM_MODE_FLAG_POL_DE_NEGEDGE)
+ sig_cfg.clk_pol = CLK_POL_ACTIVE_LOW;
+ else if (mode-private_flags DRM_MODE_FLAG_POL_DE_PRESERVE)
+ sig_cfg.clk_pol = CLK_POL_PRESERVE;
+ else
+ sig_cfg.clk_pol = CLK_POL_ACTIVE_LOW;
This is completely messed up. POL_PIXDATA should obviously define the
clock edge at which the pixel data is sampled and thus should determine
the value of sig_cfg.clk_pol and POL_DE should determine the value of
sig_cfg.enable_pol.
Lothar Waßmann
--
___
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | i...@karo-electronics.de
___
--
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
Hi,
Laurent Pinchart wrote:
Hi Lothar,
On Tuesday 18 March 2014 08:50:30 Lothar Waßmann wrote:
Laurent Pinchart wrote:
On Monday 17 March 2014 16:14:36 Lothar Waßmann wrote:
Laurent Pinchart wrote:
On Monday 17 March 2014 14:41:09 Andrzej Hajda wrote:
On 03/13/2014 06:17 PM, Denis Carikli wrote:
We need a way to pass signal polarity informations
between DRM panels, and the display drivers.
To do that, a pol_flags field was added to drm_display_mode.
Signed-off-by: Denis Carikli de...@eukrea.com
---
ChangeLog v10-v11:
- Since the imx-drm won't be able to retrive its regulators
from the device tree when using display-timings nodes,
and that I was told that the drm simple-panel driver
already supported that, I then, instead, added what was
lacking to make the eukrea displays work with the
drm-simple-panel driver.
That required a way to get back the display polarity
informations from the imx-drm driver without affecting
userspace.
---
include/drm/drm_crtc.h |8
1 file changed, 8 insertions(+)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f764654..61a4fe1 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -131,6 +131,13 @@ enum drm_mode_status {
#define DRM_MODE_FLAG_3D_MAX
DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
+#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGEBIT(1)
+#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGEBIT(2)
+#define DRM_MODE_FLAG_POL_PIXDATA_PRESERVE BIT(3)
+#define DRM_MODE_FLAG_POL_DE_NEGEDGE BIT(4)
+#define DRM_MODE_FLAG_POL_DE_POSEDGE BIT(5)
+#define DRM_MODE_FLAG_POL_DE_PRESERVEBIT(6)
Could you add some description to these flags.
What are *_PRESERVE flags for?
Are those flags 1:1 compatible with respective 'videomode:flags'?
I guess DE flags should be rather DRM_MODE_FLAG_POL_DE_(LOW|HIGH),
am I right?
Possibly nitpicking, I wouldn't call the clock edge on which data
signals are generated/sampled data polarity. This is clock polarity
information.
Have you seen cases where pixel data and DE are geenrated or need to
be sampled on different edges ?
DE is not a clock signal, but an 'Enable' signal whose value (high or
low) defines the window in which the pixel data is valid.
The flag defines whether data is valid during the HIGH or LOW period of
DE.
The DRM_MODE_FLAG_POL_DE_(LOW|HIGH) do, by my impression of the proposed
new DRM_MODE_FLAG_POL_DE_*EDGE flags is that they define sampling clock
edges, not active levels.
The current naming of the flags gives the impression that they describe
the sampling edges of a clock signal. But the DE signal in fact is not
a clock signal but a level sensitive gating signal.
That's not my point. I *know* that DE is a data gating signal with a polarity
already defined by the DRM_MODE_FLAG_POL_DE_(LOW|HIGH) flags. Like all other
signals it gets generated on a clock edge and is sampled on a clock edge. The
DRM_MODE_FLAG_POL_DE_*EDGE flags proposed above describe seem to describe
just
The important word here is 'seem'.
Lothar Waßann
--
___
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | i...@karo-electronics.de
___
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 47/48] adv7604: Add LLC polarity configuration
On 03/11/2014 12:15 AM, Laurent Pinchart wrote:
Add an inv_llc_pol field to platform data to control the clock polarity.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Reviewed-by: Hans Verkuil hans.verk...@cisco.com
Regards,
Hans
---
drivers/media/i2c/adv7604.c | 3 ++-
include/media/adv7604.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index de44213..95cc911 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2429,7 +2429,8 @@ static int adv7604_core_init(struct v4l2_subdev *sd)
cp_write(sd, 0x69, 0x30); /* Enable CP CSC */
/* VS, HS polarities */
- io_write(sd, 0x06, 0xa0 | pdata-inv_vs_pol 2 | pdata-inv_hs_pol
1);
+ io_write(sd, 0x06, 0xa0 | pdata-inv_vs_pol 2 |
+ pdata-inv_hs_pol 1 | pdata-inv_llc_pol);
/* Adjust drive strength */
io_write(sd, 0x14, 0x40 | pdata-dr_str_data 4 |
diff --git a/include/media/adv7604.h b/include/media/adv7604.h
index 6d69207..7a8462f 100644
--- a/include/media/adv7604.h
+++ b/include/media/adv7604.h
@@ -114,6 +114,7 @@ struct adv7604_platform_data {
/* IO register 0x06 */
unsigned inv_vs_pol:1;
unsigned inv_hs_pol:1;
+ unsigned inv_llc_pol:1;
/* IO register 0x14 */
enum adv7604_drive_strength dr_str_data;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 36/48] adv7604: Make output format configurable through pad format operations
On 03/18/2014 02:02 PM, Laurent Pinchart wrote:
Hi Hans,
On Tuesday 18 March 2014 10:32:32 Hans Verkuil wrote:
Hi Laurent,
I've tested it and I thought I was going crazy. Everything was fine after
applying this patch, but as soon as I applied the next patch (37/48) the
colors were wrong. But that patch had nothing whatsoever to do with the
bus ordering. You managed to make a small but crucial bug and it was pure
bad luck that it ever worked.
See details below:
On 03/11/14 16:10, Laurent Pinchart wrote:
Replace the dummy video format operations by pad format operations that
configure the output format.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/i2c/adv7604.c | 280 +++
include/media/adv7604.h | 56 -
2 files changed, 275 insertions(+), 61 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 851b350..5aa7c29 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -53,6 +53,28 @@ MODULE_LICENSE(GPL);
/* ADV7604 system clock frequency */
#define ADV7604_fsc (28636360)
+#define ADV7604_RGB_OUT(1 1)
+
+#define ADV7604_OP_FORMAT_SEL_8BIT (0 0)
+#define ADV7604_OP_FORMAT_SEL_10BIT(1 0)
+#define ADV7604_OP_FORMAT_SEL_12BIT(2 0)
+
+#define ADV7604_OP_MODE_SEL_SDR_422(0 5)
+#define ADV7604_OP_MODE_SEL_DDR_422(1 5)
+#define ADV7604_OP_MODE_SEL_SDR_444(2 5)
+#define ADV7604_OP_MODE_SEL_DDR_444(3 5)
+#define ADV7604_OP_MODE_SEL_SDR_422_2X (4 5)
+#define ADV7604_OP_MODE_SEL_ADI_CM (5 5)
+
+#define ADV7604_OP_CH_SEL_GBR (0 5)
+#define ADV7604_OP_CH_SEL_GRB (1 5)
+#define ADV7604_OP_CH_SEL_BGR (2 5)
+#define ADV7604_OP_CH_SEL_RGB (3 5)
+#define ADV7604_OP_CH_SEL_BRG (4 5)
+#define ADV7604_OP_CH_SEL_RBG (5 5)
Note that these values are shifted 5 bits to the left...
[snip]
+struct adv7604_format_info {
+ enum v4l2_mbus_pixelcode code;
+ u8 op_ch_sel;
+ bool rgb_out;
+ bool swap_cb_cr;
+ u8 op_format_sel;
+};
[snip]
+static const struct adv7604_format_info adv7604_formats[] = {
+ { V4L2_MBUS_FMT_RGB888_1X24, ADV7604_OP_CH_SEL_RGB, true, false,
+ ADV7604_OP_MODE_SEL_SDR_444 | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_YUYV8_2X8, ADV7604_OP_CH_SEL_RGB, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_YVYU8_2X8, ADV7604_OP_CH_SEL_RGB, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_YUYV10_2X10, ADV7604_OP_CH_SEL_RGB, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_10BIT },
+ { V4L2_MBUS_FMT_YVYU10_2X10, ADV7604_OP_CH_SEL_RGB, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_10BIT },
+ { V4L2_MBUS_FMT_YUYV12_2X12, ADV7604_OP_CH_SEL_RGB, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_12BIT },
+ { V4L2_MBUS_FMT_YVYU12_2X12, ADV7604_OP_CH_SEL_RGB, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422 | ADV7604_OP_FORMAT_SEL_12BIT },
+ { V4L2_MBUS_FMT_UYVY8_1X16, ADV7604_OP_CH_SEL_RBG, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_VYUY8_1X16, ADV7604_OP_CH_SEL_RBG, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_YUYV8_1X16, ADV7604_OP_CH_SEL_RGB, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_YVYU8_1X16, ADV7604_OP_CH_SEL_RGB, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_8BIT },
+ { V4L2_MBUS_FMT_UYVY10_1X20, ADV7604_OP_CH_SEL_RBG, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_10BIT },
+ { V4L2_MBUS_FMT_VYUY10_1X20, ADV7604_OP_CH_SEL_RBG, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_10BIT },
+ { V4L2_MBUS_FMT_YUYV10_1X20, ADV7604_OP_CH_SEL_RGB, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_10BIT },
+ { V4L2_MBUS_FMT_YVYU10_1X20, ADV7604_OP_CH_SEL_RGB, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_10BIT },
+ { V4L2_MBUS_FMT_UYVY12_1X24, ADV7604_OP_CH_SEL_RBG, false, false,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_12BIT },
+ { V4L2_MBUS_FMT_VYUY12_1X24, ADV7604_OP_CH_SEL_RBG, false, true,
+ ADV7604_OP_MODE_SEL_SDR_422_2X | ADV7604_OP_FORMAT_SEL_12BIT },
+ { V4L2_MBUS_FMT_YUYV12_1X24, ADV7604_OP_CH_SEL_RGB, false, false,
+
Re: [PATCH 3/3] [media] atmel-isi: add primary DT support
Hi Josh,
Thank you for the patch.
On Tuesday 18 March 2014 19:19:54 Josh Wu wrote:
This patch add the DT support for Atmel ISI driver.
It use the same v4l2 DT interface that defined in video-interfaces.txt.
Signed-off-by: Josh Wu josh...@atmel.com
Cc: devicet...@vger.kernel.org
---
.../devicetree/bindings/media/atmel-isi.txt| 51 +
drivers/media/platform/soc_camera/atmel-isi.c | 33 -
2 files changed, 82 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/atmel-isi.txt
diff --git a/Documentation/devicetree/bindings/media/atmel-isi.txt
b/Documentation/devicetree/bindings/media/atmel-isi.txt new file mode
100644
index 000..07f00eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/atmel-isi.txt
@@ -0,0 +1,51 @@
+Atmel Image Sensor Interface (ISI) SoC Camera Subsystem
+--
+
+Required properties:
+- compatible: must be atmel,at91sam9g45-isi
+- reg: physical base address and length of the registers set for the
device;
+- interrupts: should contain IRQ line for the ISI;
+- clocks: list of clock specifiers, corresponding to entries in
+ the clock-names property;
+- clock-names: must contain isi_clk, which is the isi peripherial clock.
+ isi_mck is optinal, it is the master clock output to
sensor.
The mck clock should be handled by the sensor driver instead. I know we have a
legacy mode in the atmel-isi driver to manage that clock internally, but let's
not propagate that to DT. I would also drop the isi_ prefix from the isi_clk
name.
You should also describe the port node. You can just mention the related
bindings document, and state that the ISI has a single port.
+Optional properties:
+- atmel,isi-disable-preview: a boolean property to disable the preview
channel;
That doesn't really sound like a hardware property to me. Isn't it full mode
related to software configuration instead, which should be performed at
runtime by userspace ?
+
+Example:
+ isi: isi@f0034000 {
+ compatible = atmel,at91sam9g45-isi;
+ reg = 0xf0034000 0x4000;
+ interrupts = 37 IRQ_TYPE_LEVEL_HIGH 5;
+
+ clocks = isi_clk, pck1;
+ clock-names = isi_clk, isi_mck;
+
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_isi pinctrl_pck1_as_isi_mck;
+
+ port {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ isi_0: endpoint {
+ remote-endpoint = ov2640_0;
+ };
+ };
+ };
+
+ i2c1: i2c@f0018000 {
+ ov2640: camera@0x30 {
+ compatible = omnivision,ov2640;
+ reg = 0x30;
+
+ port {
+ ov2640_0: endpoint {
+ remote-endpoint = isi_0;
+ bus-width = 8;
+ };
+ };
+ };
+ };
+
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c index 93bf1cb..1822129
100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -19,6 +19,7 @@
#include linux/interrupt.h
#include linux/kernel.h
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/slab.h
@@ -33,6 +34,7 @@
#define VID_LIMIT_BYTES (16 * 1024 * 1024)
#define MIN_FRAME_RATE 15
#define FRAME_INTERVAL_MILLI_SEC (1000 / MIN_FRAME_RATE)
+#define ISI_DEFAULT_MCLK_FREQ2500
/* Frame buffer descriptor */
struct fbd {
@@ -878,6 +880,22 @@ static int atmel_isi_remove(struct platform_device
*pdev) return 0;
}
+static int atmel_isi_probe_dt(struct atmel_isi *isi,
+ struct platform_device *pdev)
+{
+ struct device_node *node = pdev-dev.of_node;
+
+ isi-pdata.full_mode = !of_property_read_bool(node,
+ atmel,isi-disable-preview);
+
+ /* Default settings for ISI */
+ isi-pdata.mck_hz = ISI_DEFAULT_MCLK_FREQ;
+ isi-pdata.frate = ISI_CFG1_FRATE_CAPTURE_ALL;
+ isi-pdata.data_width_flags = ISI_DATAWIDTH_8 | ISI_DATAWIDTH_10;
+
+ return 0;
+}
+
static int atmel_isi_probe(struct platform_device *pdev)
{
unsigned int irq;
@@ -889,7 +907,7 @@ static int atmel_isi_probe(struct platform_device *pdev)
struct isi_platform_data *pdata;
pdata = dev-platform_data;
- if (!pdata || !pdata-data_width_flags) {
+ if ((!pdata || !pdata-data_width_flags) !pdev-dev.of_node) {
dev_err(pdev-dev,
No config available for Atmel ISI\n);
return -EINVAL;
[PATCH] staging: omap24xx: fix coding style
Fix missing parentheses in macros Errors found by checkpatch.pl Signed-off-by: Ioana Ileana ile...@enst.fr --- drivers/staging/media/omap24xx/tcm825x.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/media/omap24xx/tcm825x.h b/drivers/staging/media/omap24xx/tcm825x.h index e2d1bcd..bfb72ee 100644 --- a/drivers/staging/media/omap24xx/tcm825x.h +++ b/drivers/staging/media/omap24xx/tcm825x.h @@ -21,8 +21,8 @@ #define TCM825X_NAME tcm825x -#define TCM825X_MASK(x) x 0x00ff -#define TCM825X_ADDR(x) (x 0xff00) 8 +#define TCM825X_MASK(x) (x 0x00ff) +#define TCM825X_ADDR(x) ((x 0xff00) 8) /* The TCM825X I2C sensor chip has a fixed slave address of 0x3d. */ #define TCM825X_I2C_ADDR 0x3d -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
How can I feed more data to a stream after I stream on?
I am using v4l2 m2m framework to develop a resize driver. I have an image , pass it to the driver and it generated a resize output image. My v4l2 sequence is 1. qbuf OUTPUT, CAPTURE 2. stream on OUTPUT, CAPTURE 3. dqbuf OUTPUT, CAPTURE 4. stream off OUTPUT, CAPTURE this works if i have a full frame of image before i start streaming. But what I only have partial buffers when I start streaming, how can I qbuf more buffer after I 'stream on' OUTPUT, I try this, but this fail 1. qbuf OUTPUT, CAPTURE (I qbuf only partial OUTPUT) 2. stream on OUTPUT, CAPTURE // do this in a loop: 3. dqbuf OUTPUT (I want to queue more OUTPUT as they become available) 4. qbuf OUTPUT // now I am done, I want to dqbuf my output 5. dqbuf CAPTURE 6. stream off OUTPUT, CAPTURE I try to do dqbuf/qbuf OUTPUT in step #3, #4 above, but it just stuck in dqbuf OUTPUT. How can I queue more of my input data after I stream on? Thank you. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Mar 19 04:00:17 CET 2014 git branch: test git hash: ed97a6fe5308e5982d118a25f0697b791af5ec50 gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0 host hardware: x86_64 host os:3.13-5.slh.4-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-i686: OK linux-3.14-rc1-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK linux-3.13-x86_64: OK linux-3.14-rc1-x86_64: OK apps: OK spec-git: OK sparse version: v0.5.0 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
