On Fri, May 05, 2017 at 08:40:43PM +0300, Ville Syrjälä wrote:
> On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote:
> > El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:
> >
> > > In several instances the driver passes an 'enum pipe' value to a
> > > function expec
On Sun, May 07, 2017 at 07:52:14PM -0600, Jens Axboe wrote:
> On 05/07/2017 11:56 AM, Daniel Vetter wrote:
> > On Sun, May 7, 2017 at 7:46 PM, Jens Axboe wrote:
> >> On 05/07/2017 11:12 AM, ville.syrj...@linux.intel.com wrote:
> >>> From: Ville Syrjälä
> >>>
> >>> Add a new Kconfig option to enab
On Sun, May 07, 2017 at 08:12:52PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add a new Kconfig option to enable/disable the extra warnings
> from the vblank evade code. For now we'll keep the warning
> about an actually missed vblank always enabled as that can have
> a
On Sat, May 06, 2017 at 11:40:17PM +0800, Geliang Tang wrote:
> Use memdup_user_nul() helper instead of open-coding to simplify the
> code.
>
> Signed-off-by: Geliang Tang
Thx for the patch, applied to drm-intel.git.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 13 +++--
> d
On Sat, 6 May 2017 13:34:44 +0200
Mario Kleiner wrote:
> Just please make sure that one (user configurable/opt-in if necessary)
> policy from the beginning is to allow leasing out any output to
> applications, not just HMDs. My type of scientific/medical applications
> would benefit as soon as
On Thu, May 04, 2017 at 03:11:39PM +0100, Jose Abreu wrote:
> This changes the connector probe helper function to use the new
> encoder->mode_valid() and crtc->mode_valid() helper callbacks to
> validate the modes.
>
> The new callbacks are optional so the behaviour remains the same
> if they are
On Thu, May 04, 2017 at 03:11:38PM +0100, Jose Abreu wrote:
> This adds a new callback to crtc, encoder and bridge helper functions
> called mode_valid(). This callback shall be implemented if the
> corresponding component has some sort of restriction in the modes
> that can be displayed. A NULL ca
https://bugs.freedesktop.org/show_bug.cgi?id=100949
--- Comment #1 from Michel Dänzer ---
Can you bisect?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists
On Thu, May 04, 2017 at 04:13:51PM +0100, Jose Abreu wrote:
> On 04-05-2017 15:40, Ville Syrjälä wrote:
> > On Thu, May 04, 2017 at 03:11:41PM +0100, Jose Abreu wrote:
> >> + struct drm_encoder *encoder,
> >> + struct drm_crt
On Thu, May 04, 2017 at 03:11:37PM +0100, Jose Abreu wrote:
> This series is a follow up from the discussion at [1]. We start by
> introducing crtc->mode_valid(), encoder->mode_valid() and
> bridge->mode_valid() callbacks which will be used in followup
> patches.
>
> Next, at 2/5 we modify the con
https://bugs.freedesktop.org/show_bug.cgi?id=100949
Luya Tshimbalanga changed:
What|Removed |Added
Attachment #131232|0 |1
is obsolete|
On Mon, 08 May 2017, Daniel Vetter wrote:
> On Fri, May 05, 2017 at 08:40:43PM +0300, Ville Syrjälä wrote:
>> On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote:
>> > El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:
>> >
>> > > In several instances the driver pass
https://bugs.freedesktop.org/show_bug.cgi?id=100919
Michel Dänzer changed:
What|Removed |Added
Summary|"Out of range" on a display |[DC] "Out of range" on a
On Sun, 07 May 2017, Hans de Goede wrote:
> @@ -1403,6 +1410,31 @@ static inline u32 intel_plane_ggtt_offset(const struct
> intel_plane_state *state)
> return i915_ggtt_offset(state->vma);
> }
>
> +static inline unsigned int
> +intel_plane_get_rotation(const struct intel_plane_state *pla
Again no apparent explanation for the split except hysterical raisins.
Merging them also makes it a bit more obviuos what's going on wrt the
runtime pm refdancing.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Reviewed-by: Sean Paul
Reviewed-by: Liviu Dudau
Signed-off-b
With all drivers converted there's only legacy dri1 drivers using it.
Not going to touch those, instead just hide it like we've done with
other dri1 driver hooks like firstopen.
In all this I didn't find any real reason why we'd needed 2 hooks, and
having symmetry between open and close just appea
I didn't spot anything that would require ordering here (well not
anywhere else either), and I'm trying to unify at least modern drivers
on one close hook.
Cc: Thierry Reding
Cc: linux-te...@vger.kernel.org
Reviewed-by: Sean Paul
Reviewed-by: Liviu Dudau
Signed-off-by: Daniel Vetter
---
drive
Again no apparent explanation for the split except hysterical raisins.
Merging them also makes it a bit more obviuos what's going on wrt the
runtime pm refdancing.
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
Reviewed-by: Sean Paul
Reviewed-by: Liviu Dudau
Signed-off-by: Daniel Vetter
---
On Mon, May 08, 2017 at 10:26:30AM +0200, Daniel Vetter wrote:
> Again no apparent explanation for the split except hysterical raisins.
> Merging them also makes it a bit more obviuos what's going on wrt the
> runtime pm refdancing.
>
> Cc: Ben Skeggs
> Cc: nouv...@lists.freedesktop.org
> Reviewe
Hi,
This series adds a few new OMAP_BO flags to help the userspace manage
situations where it needs to use lots of buffers, and would currently run out
of TILER space.
This needs to be rebased on Laurent's "GEM object fixes" series, but I don't
expect any major conflicts.
Tomi
Tomi Valkeinen (
On SoCs with TILER, we have to ways to allocate buffers: normal
dma_alloc or via TILER (which basically functions as an IOMMU). TILER
can map 128MB at a time, and we only map the TILER buffers when they are
used (i.e. not at alloc time). If TILER is present, omapdrm always
uses TILER.
There are us
Add omap_gem_put_paddr_locked() which is a version of
omap_gem_put_paddr() that expects the caller to hold the struct_mutex.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_gem.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/o
Hi,
On 08-05-17 10:25, Jani Nikula wrote:
On Sun, 07 May 2017, Hans de Goede wrote:
@@ -1403,6 +1410,31 @@ static inline u32 intel_plane_ggtt_offset(const struct
intel_plane_state *state)
return i915_ggtt_offset(state->vma);
}
+static inline unsigned int
+intel_plane_get_rotatio
From: Markus Elfring
Date: Mon, 8 May 2017 11:05:05 +0200
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (4):
Combine two function calls into one in dma_buf_debug_show()
Improve a size determination in dma_buf_attach()
Adjust a null pointe
From: Markus Elfring
Date: Mon, 8 May 2017 10:32:44 +0200
A bit of data was put into a sequence by two separate function calls.
Print the same data by a single function call instead.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/dma-buf/dm
Dear all,
This is an updated proposal for extending EXYNOS DRM API with generic support
for hardware modules, which can be used for processing image data from the
one memory buffer to another. Typical memory-to-memory operations are:
rotation, scaling, colour space conversion or mix of them. This
This patch extends Exynos DRM API with picture processor hardware modules.
Such modules can be used for processing image data from the one memory buffer
to another. Typical memory-to-memory operations are: rotation, scaling, colour
space conversion or mix of them.
The proposed API is heavily inspi
From: Markus Elfring
Date: Mon, 8 May 2017 10:50:09 +0200
Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
Signed-off-by: Mark
This patch converts Exynos Rotator driver from Exynos IPP API to
Exynos DRM Picture Processor API.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/Kconfig | 1 -
drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 +
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 493 +
From: Markus Elfring
Date: Mon, 8 May 2017 10:54:17 +0200
The script "checkpatch.pl" pointed information out like the following.
Comparison to NULL could be written "!attach"
Thus adjust this expression.
Signed-off-by: Markus Elfring
---
drivers/dma-buf/dma-buf.c | 2 +-
1 file changed, 1 in
From: Markus Elfring
Date: Mon, 8 May 2017 10:55:42 +0200
Three single characters (line breaks) should be put into a sequence.
Thus use the corresponding function "seq_putc".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/dma-buf/sync_debug
Hi Christophe,
s/fix some error handling in 'ls_ucode_img_load_gr/plug memory leak in
ls_ucode_img_load_gr() error path/
On 8 May 2017 at 08:46, Christophe JAILLET
wrote:
> The last goto looks spurious because it releases less resources than the
> previous one.
> Add a new label in order to free
On 06/05/17 14:58, Hans Verkuil wrote:
> My assumption was that hdmi_display_disable() was called when the hotplug
> would go
> away. But I discovered that that isn't the case, or at least not when X is
> running.
> It seems that the actual HPD check is done in hdmic_detect() in
> omapdrm/displa
On Sun, May 07, 2017 at 11:10:56AM +0200, Hans de Goede wrote:
> On some (Bay Trail) devices the LCD panel is mounted upside-down.
>
> This commit uses the code to read back the initial rotation of the
> primary plane in get_initial_plane_config from Ville Syrjala's
> "drm/fb-helper: Inherit rotat
On 05/08/2017 12:26 PM, Tomi Valkeinen wrote:
> On 06/05/17 14:58, Hans Verkuil wrote:
>
>> My assumption was that hdmi_display_disable() was called when the hotplug
>> would go
>> away. But I discovered that that isn't the case, or at least not when X is
>> running.
>> It seems that the actual
On Fri, 05 May 2017 07:25:14 -0700
Keith Packard wrote:
> Pekka Paalanen writes:
>
> > I disagree on the details, more below.
>
> > Such a RandR request is something I would not like to have to replicate
> > on Wayland. The display server contains the policy, it should not just
> > expose ev
Hi,
On 08-05-17 12:44, Ville Syrjälä wrote:
On Sun, May 07, 2017 at 11:10:56AM +0200, Hans de Goede wrote:
On some (Bay Trail) devices the LCD panel is mounted upside-down.
This commit uses the code to read back the initial rotation of the
primary plane in get_initial_plane_config from Ville S
From: Markus Elfring
Date: Mon, 8 May 2017 13:16:15 +0200
Two update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Use seq_putc() in etnaviv_buffer_dump()
Delete an error message for a failed memory allocation in etnaviv_bind()
drivers/gpu/drm/et
From: Markus Elfring
Date: Mon, 8 May 2017 13:00:28 +0200
Two single characters (line breaks) should be put into a sequence.
Thus use the corresponding function "seq_putc".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/etnaviv/etna
From: Markus Elfring
Date: Mon, 8 May 2017 13:08:11 +0200
The script "checkpatch.pl" pointed information out like the following.
WARNING: Possible unnecessary 'out of memory' message
Thus remove such a statement here.
Link:
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Ref
The dss_get_core_pdev() function is unused, remove it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/core.c | 5 -
drivers/gpu/drm/omapdrm/dss/dss.h | 1 -
2 files changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/core.c
b/drivers/gpu/drm/omapdrm/dss/core.
The DSI PLL hardware data and DSS channels are selected based on the
OMAP SoC model. There's no need for fine-grained model information, as
the driver only needs to differentiate between OMAP3, OMAP4 and OMAP5.
As this can be done through the DSI compatible string, store the
corresponding informati
The devm_ioremap_resource() call can handle being given a NULL resource,
and prints an error message when mapping fails. Switch the remaining
devm_ioremap() calls to devm_ioremap_resource() and remove all
extraneous resource NULL checks and error messages printed manually by
the driver.
Signed-off
Don't rely on callback functions provided by the platform, but access
the syscon internally to mux the DSI pins.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/core.c | 20 --
drivers/gpu/drm/omapdrm/dss/dsi.c | 82 --
drivers/gpu/drm
Hello,
This patch series is a second, extended version of the code previously posted
as "[PATCH/RFC 0/7] Remove the omapdrm device from platform code".
The omapdss/omapdrm initialization code is quite a mess. The physical devices
are instantiated from DT, but two virtual devices named omapdrm and
The default display name is both unused and never set by platform data.
Remove default display name module parameter, platform data field and
runtime infrastructure.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Don't remove the platform callbacks as they're still used by the
omapfb
The omapdrm exposes the SoC version to userspace through an integer that
contains the OMAP model (e.g. 0x3430 for the OMAP3430). This is an
unfortunate choice of userspace API as it's both conceptually wrong
(userspace nowadays should use /sys/bus/soc/ for that purpose) and
inaccurate as many model
All OMAP platforms use DT nowadays, drop support for non-DT devices.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/display.c | 19 ++-
drivers/gpu/drm/omapdrm/dss/dsi.c | 93 +++
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 8 ++-
drivers/gpu
No device is ever registered that binds with the driver, the DPI port is
handled manually. Remove the DPI platform driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/core.c | 6 ---
drivers/gpu/drm/omapdrm/dss/dpi.c | 93 --
drivers/gpu/
Move the two function pointers to a new dss_ops structure. This will
allow merging the dss_features and omap_dss_features structures without
having to expose the DPI source selection and LCD clock muxing functions
in header files.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/d
The DSS internal features are derived from the platform device
compatible string which is available at probe time. Don't delay
initialization until bind time. This prepares for the merge of the two
DSS features structures that will be needed before the DSS is bound.
Signed-off-by: Laurent Pinchart
The DPI code only needs to differentiate between major OMAP revisions,
which can be obtained from the DSS compatible string. Replace the OMAP
SoC model checks to prepare for removal of the OMAP SoC version platform
data.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 59
Use the compatible string instead of the OMAP SoC revision to determine
device features. On OMAP34xx the features depend on the ES revision that
can not be determined from the compatible string. Use soc_device_match()
in that case.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/
No device is ever registered that binds with the driver, the SDI port is
handled manually. Remove the SDI platform driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/core.c | 6 -
drivers/gpu/drm/omapdrm/dss/dss.h | 3 ---
drivers/gpu/drm/omapdrm/dss/sdi.c | 54 -
PHY features are stored in a global variable, while they should be
properties of the PHY object. As existing OMAP platforms have a single
HDMI PHY this doesn't cause any issue, but doesn't follow the driver
model.
Move the PHY features to the HDMI PHY data structure to follow the
driver model and
Use the compatible string instead of the OMAP SoC revision to determine
device features. The various OMAP3-based SoCs can be told apart from the
compatible string, use soc_device_match() to tell them apart.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dss.c | 97 --
The HDMI audio driver only needs to know which generation of HDMI
transmitter it deals with, not the detailed SoC model. Pass the version
number as an integer to prepare for removal of the OMAP SoC version from
the omapdrm driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/h
debugfs code is spread between the core and dss drivers. In preparation
for removal of the core driver, move it all to the dss driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/core.c | 80 --
drivers/gpu/drm/omapdrm/dss/dss.c | 77 +
The omapdrm platform device is a virtual device created for the sole
purpose of handling the omapdss/omapdrm driver split. It should
eventually be removed. As a first step to ease refactoring move its
registration from platform code to driver code.
The omapdrm driver name must be changed internall
The HDMI PHY features are dependent on the HDMI transmitter model. The
PHY driver contains features for all supported transmitters, and selects
the appropriate features based on the OMAP SoC version.
It makes more sense to store the features in the HDMI transmitter
drivers and pass them to the HDM
In preparation for removal of the core module, move the shutdown()
handler from core to dss.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/core.c | 20
drivers/gpu/drm/omapdrm/dss/dss.c | 16
2 files changed, 16 insertions(+), 20 deletions
The HDMI wrapper code only needs to differentiate between major OMAP
revisions, which can be obtained from the HDMI transmitter compatible
string. Replace the OMAP SoC model checks to prepare for removal of the
OMAP SoC version platform data.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/o
The omapdrm driver doesn't need the omapdss device anymore. Although it
can't be removed completely as the fbdev driver still requires it, we
can condition its registration to the usage of the omapfb driver.
Signed-off-by: Laurent Pinchart
---
arch/arm/mach-omap2/display.c | 111
The omapdrm platform device is unused, as a replacement is now
registered in the omapdss driver. Remove it.
Signed-off-by: Laurent Pinchart
---
arch/arm/mach-omap2/Makefile | 2 +-
arch/arm/mach-omap2/display.c | 7 --
arch/arm/mach-omap2/display.h | 1 -
arch/arm/mach-omap2/drm.c |
The HDMI PLL hardware data are dependent on the HDMI transmitter model.
The PLL driver contains hardware data for all supported transmitters,
and selects the appropriate hardware data based on the OMAP SoC version.
It makes more sense to store the PLL hardware data in the HDMI
transmitter drivers
On Thu, May 04, 2017 at 03:20:22PM +0200, Daniel Vetter wrote:
> On Wed, May 03, 2017 at 05:09:08PM +0300, Ville Syrjälä wrote:
> > On Wed, May 03, 2017 at 09:26:38AM +0200, Daniel Vetter wrote:
> > > In the previous patch we've implemented hwmode tracking a la i915 for
> > > the vblank timestamp c
The omapdrm platform data are not used anymore, remove them.
Signed-off-by: Laurent Pinchart
---
include/linux/platform_data/omap_drm.h | 53 --
1 file changed, 53 deletions(-)
delete mode 100644 include/linux/platform_data/omap_drm.h
diff --git a/include/linux/
The omapdss driver (not to be confused with the omapdss_dss driver) is
now a dummy driver with empty probe and remove functions. Remove it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/core.c| 48 ---
drivers/gpu/drm/omapdrm/dss/omapdss.h |
Both structures describe features of a particular OMAP DSS version,
there's no reason to keep them separate. Merge them together, allowing
initialization of the features based on the DSS compatible string
instead of the OMAP SoC version.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdr
The OMAP implementation of the set_min_bus_tput() API is a no-op.
There's no point in forwarding the driver calls to the platform code.
Remove the use of the related platform data callback, but keep the
internal function as a reminder that the feature will need to be
implemented when the OMAP platf
https://bugs.freedesktop.org/show_bug.cgi?id=100437
--- Comment #5 from Christian Lanig ---
The bug is not fixed but it only happens on a cold boot for me. When I reboot
the PC these messages disappear.
There also seem to be reports about comparable behavior with older AMD systems.
It is perhaps
From: Markus Elfring
Date: Mon, 8 May 2017 13:42:03 +0200
A single character (line break) should be put into a sequence.
Thus use the corresponding function "seq_putc".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/tinydrm/mipi-dbi
On Sun, May 07, 2017 at 11:10:56AM +0200, Hans de Goede wrote:
> On some (Bay Trail) devices the LCD panel is mounted upside-down.
>
> This commit uses the code to read back the initial rotation of the
> primary plane in get_initial_plane_config from Ville Syrjala's
> "drm/fb-helper: Inherit rotat
Hi,
On Monday, May 08, 2017 02:32:39 PM Laurent Pinchart wrote:
> The default display name is both unused and never set by platform data.
> Remove default display name module parameter, platform data field and
> runtime infrastructure.
>
> Signed-off-by: Laurent Pinchart
For fbdev part:
Acked
HI,
On 08-05-17 14:27, Chris Wilson wrote:
On Sun, May 07, 2017 at 11:10:56AM +0200, Hans de Goede wrote:
On some (Bay Trail) devices the LCD panel is mounted upside-down.
This commit uses the code to read back the initial rotation of the
primary plane in get_initial_plane_config from Ville Sy
On 08/05/17 14:32, Laurent Pinchart wrote:
> The devm_ioremap_resource() call can handle being given a NULL resource,
> and prints an error message when mapping fails. Switch the remaining
> devm_ioremap() calls to devm_ioremap_resource() and remove all
> extraneous resource NULL checks and error m
With Laura's introduction of the fake platform device for importing
dmabuf, we add a second static that is logically tied to the vgem_device.
Convert vgem over to using the struct drm_device subclassing, so that
the platform device is stored inside its owner.
Signed-off-by: Chris Wilson
Cc: Laura
Hi Marek,
A couple of small nitpicks from UAPI POV.
On 8 May 2017 at 10:11, Marek Szyprowski wrote:
> --- a/include/uapi/drm/exynos_drm.h
> +++ b/include/uapi/drm/exynos_drm.h
> +struct drm_exynos_pp_get_res {
> + __u64 pp_id_ptr;
> + __u32 count_pps;
Add __u32 pad - sizeof(struct
On Tue, Apr 25, 2017 at 1:18 PM, Marco Franchi wrote:
> Add driver for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480)
> TFT with Touch-Panel.
>
> Datasheet available at:
> http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf
>
> Seiko 43WVF1G panel has two power supplies: AVDD and DVDD and the
Hi Tomi,
On Monday 08 May 2017 15:52:07 Tomi Valkeinen wrote:
> On 08/05/17 14:32, Laurent Pinchart wrote:
> > The devm_ioremap_resource() call can handle being given a NULL resource,
> > and prints an error message when mapping fails. Switch the remaining
> > devm_ioremap() calls to devm_ioremap_
Hi Tomi,
Thank you for the patch.
On Thursday 27 Apr 2017 13:27:49 Tomi Valkeinen wrote:
> We have been using DRM_MODE_CONNECTOR_Unknown for many of our outputs
> because there has not been a proper connector type for them.
>
> We now have connector type for DPI so let's take it into use. At the
Hi Tomi,
Thank you for the patch.
On Thursday 27 Apr 2017 13:27:50 Tomi Valkeinen wrote:
> ovl_enabled() is not used anywhere, so remove it.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/dispc.c | 6 --
> drivers/gpu/drm/omapdrm/ds
Hi Tomi,
Thank you for the patch.
On Thursday 27 Apr 2017 13:27:51 Tomi Valkeinen wrote:
> At the moment we have ovl_set_channel_out() to configure the output
> channel of an overlay. It makes sense to have this configuration as part
> of the reset of overlay configuration, and in DSS6+ we need t
Hi Tomi,
Thank you for the patch.
On Thursday 27 Apr 2017 13:27:52 Tomi Valkeinen wrote:
> We only use read_irqenable() to flush posted write. Instead of having a
> separate function for this, do the flush implicitly in write_irqenable().
> Thus we can remove read_irqenable().
>
> Signed-off-by:
Hi Tomi,
Thank you for the patch.
On Thursday 27 Apr 2017 13:27:53 Tomi Valkeinen wrote:
> Fix a few type issues that cause compile warnings on 64 bit ARM
> compiler. The change should not affect 32bit platforms.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> driver
2017-05-08 SF Markus Elfring :
> From: Markus Elfring
> Date: Mon, 8 May 2017 10:32:44 +0200
>
> A bit of data was put into a sequence by two separate function calls.
> Print the same data by a single function call instead.
>
> This issue was detected by using the Coccinelle software.
>
> Sign
2017-05-08 SF Markus Elfring :
> From: Markus Elfring
> Date: Mon, 8 May 2017 10:50:09 +0200
>
> Replace the specification of a data structure by a pointer dereference
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a bit safer according to the Linux c
Hi Tomi,
Thank you for the patch.
On Thursday 27 Apr 2017 13:27:54 Tomi Valkeinen wrote:
> Define compat_ioctl in omapdriver_fops to make it possible to use 32bit
> apps on 64bit platform.
>
> Signed-off-by: Tomi Valkeinen
None of the omapdrm custom ioctls seem to need compat handling, so
Rev
2017-05-08 SF Markus Elfring :
> From: Markus Elfring
> Date: Mon, 8 May 2017 10:54:17 +0200
>
> The script "checkpatch.pl" pointed information out like the following.
>
> Comparison to NULL could be written "!attach"
>
> Thus adjust this expression.
>
> Signed-off-by: Markus Elfring
> ---
>
Hi Markus,
Thank for your patches.
2017-05-08 SF Markus Elfring :
> From: Markus Elfring
> Date: Mon, 8 May 2017 10:55:42 +0200
>
> Three single characters (line breaks) should be put into a sequence.
> Thus use the corresponding function "seq_putc".
>
> This issue was detected by using the C
On 08/05/17 17:21, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Thursday 27 Apr 2017 13:27:49 Tomi Valkeinen wrote:
>> We have been using DRM_MODE_CONNECTOR_Unknown for many of our outputs
>> because there has not been a proper connector type for them.
>>
>> We now have
https://bugs.freedesktop.org/show_bug.cgi?id=100964
--- Comment #3 from Alex Deucher ---
Sounds like maybe a power supply issues. Do you have another power supply you
could try?
--
You are receiving this mail because:
You are the assignee for the bug.___
Hello,
This is a rebased and partially reworked version of the vb2 cache hints
support patch series posted by first myself, then Laurent and then myself
again.
I'm still posting this as RFC primarily because more testing and driver
changes will be needed. In particular, a lot of platform drivers
The buffer cache should be synchronised in buffer preparation, not when
the buffer is queued to the device. Fix this.
Mmap buffers do not need cache synchronisation since they are always
coherent.
Signed-off-by: Sakari Ailus
Acked-by: Hans Verkuil
---
drivers/media/v4l2-core/videobuf2-core.c |
Patch ccc66e73 ("ARM: 8508/2: videobuf2-dc: Let drivers specify DMA
attrs") added support for driver specific DMA attributes to
videobuf2-dma-contig but it had several issues in it.
In particular,
- cache operations were only performed on USERPTR buffers,
- DMA attributes were set only for MMAP
The V4L2_BUF_FLAG_NO_CACHE_INVALIDATE and V4L2_BUF_FLAG_NO_CACHE_CLEAN
buffer flags are currently not used by the kernel. Replace the definitions
by a single V4L2_BUF_FLAG_NO_CACHE_SYNC flag to be used by further
patches.
Different cache architectures should not be visible to the user space
which
The scatterlist should always be present when the cache would need to be
flushed. Each buffer type has its own means to provide that. Add
WARN_ON_ONCE() to check the scatterist exists.
Signed-off-by: Sakari Ailus
Acked-by: Hans Verkuil
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 8
vb2_dc_get_base_sgt() which obtains the scatterlist already prints
information on why the scatterlist could not be obtained.
Also, remove the useless warning of a failed kmalloc().
Signed-off-by: Sakari Ailus
Reviewed-by: Laurent Pinchart
Acked-by: Hans Verkuil
---
drivers/media/v4l2-core/vid
From: Samu Onkalo
The user may request to the driver (vb2) to skip the cache maintenance
operations in case the buffer does not need cache synchronisation, e.g. in
cases where the buffer is passed between hardware blocks without it being
touched by the CPU.
Also document that the prepare and fin
Document when should the user specify V4L2_BUF_FLAG_NO_CACHE_SYNC flag.
Signed-off-by: Sakari Ailus
---
Documentation/media/uapi/v4l/buffer.rst | 21 +
1 file changed, 21 insertions(+)
diff --git a/Documentation/media/uapi/v4l/buffer.rst
b/Documentation/media/uapi/v4l/buffe
1 - 100 of 208 matches
Mail list logo
