On Wed, May 27, 2015 at 02:49:17PM +0200, Lucas Stach wrote:
> Hi Alexander,
>
> Am Mittwoch, den 27.05.2015, 14:45 +0200 schrieb Alexander Holler:
> > Hello,
> >
> > I've just build and booted the Etnaviv driver as module with Kernel 4.0.4.
> >
> > When I unload the driver with rmmod an oops ha
should need to be included - drm/drm.h
takes care of including linux/types.h when building on Linux platforms.
(note: if your compiler doesn't set __linux__ then you're probably not
using the proper compiler...)
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
On Mon, Oct 19, 2015 at 04:07:47PM +0100, Liviu Dudau wrote:
> A lot of component based DRM drivers use a variant of the same code
> as the probe function. They bind the crtc ports in the first iteration
> and then scan through the child nodes and bind the encoders attached
> to the remote endpoint
On Mon, Nov 09, 2015 at 05:39:25PM +0800, Mark yao wrote:
> Hi Liviu
> Rockchip drm can't work with drm_of_component_probe function now,
>
> At drm_of_component_probe:
> component_match_add(dev, &match, compare_of, port);
> And original rockchip drm use:
>
On Mon, Nov 09, 2015 at 11:57:27AM +, Liviu Dudau wrote:
> Meanwhile, what is your suggestion regarding the patchset. I've seen David has
> sent Linus a pull request for 4.4-rc1 that includes it. Should we send a
> revert for rockchip commit and then patch later the function?
It definitely nee
On Mon, Nov 09, 2015 at 08:56:10PM +0900, Tetsuo Handa wrote:
> There are many locations that do
>
> if (memory_was_allocated_by_vmalloc)
> vfree(ptr);
> else
> kfree(ptr);
>
> but kvfree() can handle both kmalloc()ed memory and vmalloc()ed memory
> using is_vmalloc_addr(). Unless cal
On Mon, Nov 09, 2015 at 05:28:41PM +0100, Philipp Zabel wrote:
> The crtc child device driver shouldn't modify the of_node of its platform
> device in the probe function. Instead, since the previous patch, the IPU
> core driver sets the of_node when the platform device is created.
>
> Drop the now
On Wed, Nov 11, 2015 at 03:34:32PM +, Liviu Dudau wrote:
> While going through the code testing I've noticed an unbalanced
> .unbind missing drm_connector_unregister()
That actually doesn't matter, as DRM automatically tears them down anyway,
so this isn't an urgent change. However, it's good
On Mon, May 30, 2016 at 07:52:53PM +0200, Daniel Vetter wrote:
> No dev->struct_mutex anywhere to be seen.
>
> Cc: Russell King
Acked-by: Russell King
(please note the new address.)
Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line:
On Fri, Jun 03, 2016 at 10:40:48AM +0100, Liviu Dudau wrote:
> On Fri, Jun 03, 2016 at 08:58:10AM +0100, Russell King wrote:
> > Convert DT component matching to use component_match_add_release().
>
> Hi Russell,
>
> Any reason for not keeping the component_match_add() calls in the drivers?
Sorr
On Fri, Jun 03, 2016 at 12:19:41PM +0100, Liviu Dudau wrote:
> On Fri, Jun 03, 2016 at 11:36:33AM +0100, Russell King - ARM Linux wrote:
> > On Fri, Jun 03, 2016 at 10:40:48AM +0100, Liviu Dudau wrote:
> > > On Fri, Jun 03, 2016 at 08:58:10AM +0100, Russell King wrote:
> >
On Fri, Jun 03, 2016 at 11:56:40AM +0100, Robin Murphy wrote:
> Hi Russell,
>
> On 03/06/16 08:58, Russell King wrote:
> >Convert DT component matching to use component_match_add_release().
> >
> >Signed-off-by: Russell King
> >---
> > drivers/gpu/drm/arm/hdlcd_drv.c | 10 --
t; Signed-off-by: Russell King
> > ---
> > drivers/of/Makefile | 2 +-
> > drivers/of/of_component.c| 41 +++++
> > include/linux/of_component.h | 14 ++
>
> I'd prefer this to go into drivers/base/co
On Fri, Jun 03, 2016 at 05:44:30PM +0200, Thierry Reding wrote:
> On Fri, Jun 03, 2016 at 03:21:19PM +0100, Russell King wrote:
> [...]
> > diff --git a/drivers/of/of_component.c b/drivers/of/of_component.c
> [...]
> > +static void component_compare_of(struct device *dev, void *data)
> > +{
> > +
On Wed, Jun 15, 2016 at 06:21:04PM +0100, Liviu Dudau wrote:
> Could be the tda998x_drv fault, but I'm getting this splat:
>
> [1.347687] kobject_add_internal failed for card0-HDMI-A-1 (error: -2
> parent: card0)
Right, so this is -ENOENT - I expect that it's complaining that the
parent does
On Wed, Jun 15, 2016 at 09:29:38PM +0200, Daniel Vetter wrote:
> On Wed, Jun 15, 2016 at 7:21 PM, Liviu Dudau wrote:
> > Could be the tda998x_drv fault, but I'm getting this splat:
>
> Yeah, tda9998x needs to be fixed to _not_ register it's connector
> before the overall (componentized) driver is
On Mon, Jan 18, 2016 at 09:52:27AM +, Liviu.Dudau at arm.com wrote:
> On Sat, Jan 16, 2016 at 10:17:54PM +0200, Jyri Sarha wrote:
> > It just makes me wonder if drm_atomic_helper_connector_dpms() should
> > call the legacy callback automatically if DRIVER_ATOMIC is not set or
> > at least bail
Hi,
Some comments below...
On Mon, Jan 18, 2016 at 10:42:20PM +0800, Yakir Yang wrote:
> +static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi)
> +{
> + char info[HDMI_SIZE_AVI_INFOFRAME] = {0};
> + int avi_color_mode;
> + int i;
> +
> + hdmi_writeb(hdmi, HDMI_CONTROL_PACK
Co-incidentally, I also have a patch series along these same lines
created last night, only with all the review points already addressed.
I'll send it out momentarily.
Not quite fully tested because the VG core causes the kernel to oops
when reading /sys/kernel/debug/dri/1/gpu, but tested apart fr
On Tue, Jan 19, 2016 at 11:09:57AM +0100, Christian Gmeiner wrote:
> Hi Russell,
>
> 2016-01-19 10:18 GMT+01:00 Russell King :
> > + /*
> > +* For some cores, two varyings are consumed for position, so the
> > +* maximum varying count needs to be reduced by one.
> > +
On Thu, Jan 21, 2016 at 12:34:16PM +0100, Christian Gmeiner wrote:
> Hi Lucas,
>
> 2016-01-21 10:16 GMT+01:00 Lucas Stach :
> > Am Dienstag, den 19.01.2016, 09:18 + schrieb Russell King:
> >> Export further minor feature bitmasks and the varyings count from
> >> the GPU specifications register
Here's some updates to etnaviv, which augment the features and GPU
specifications which we export to userspace. This will allow us to
fix the (currently incorrect) number of varyings that GPUs such as
GC880 and GC2000 supposedly have.
While making this change, I'm also increasing the number of fe
On Thu, Jan 21, 2016 at 02:54:03PM +0100, Lucas Stach wrote:
> The retire worker is kicked for each fence, either the normal way
> by signaling the fence from the event completion interrupt or by
> the recover worker if the GPU got stuck. Moving the RPM put into
> the retire worker allows us to hav
On Tue, Jan 26, 2016 at 04:45:25PM +0100, Lucas Stach wrote:
> In case that etnaviv_gem_get_pages is unable to get the required
> pages the object mutex needs to be unlocked. Also return NULL in
> this case instead of propagating the error, as callers of this
> function might not be prepared to han
On Tue, Jan 26, 2016 at 04:45:26PM +0100, Lucas Stach wrote:
> When trying to get the vmap address of an imported buffer, we must
> call into the appropriate helper function, to allow the exporter to
> establish the vmap, instead of trying to vmap the buffer on our own.
Rather than this way, pleas
X6 and Dove, where deferred probing does happen.)
Your patch looks like the right thing to do, so I'll add it to the
component tree shortly - it should end up in linux-next in a few days
time.
Thanks.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for
On Mon, Jul 25, 2016 at 11:55:48AM +0100, Brian Starkey wrote:
> The connector shouldn't be registered until the rest of the whole device
> is set up, so that consistent state is presented to userspace.
>
> As drm_dev_register() now registers all of the connectors anyway,
> there's no need to expl
On Mon, Jul 21, 2014 at 03:43:13PM +0200, Boris BREZILLON wrote:
> How about using a list instead of an array ?
> This way we can add elements to this list when parsing the EDID.
>
> Or we can just define a maximum size for the bus_formats array when
> retrieving this info from EDID. If I'm correc
evice *dev)
> {
> struct shmob_drm_device *sdev = dev_get_drvdata(dev);
> --
> 1.8.3.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinf
{
> struct rcar_du_device *rcdu = dev_get_drvdata(dev);
> --
> 1.8.3.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
On Thu, Jul 24, 2014 at 11:47:55AM +0200, Lucas Stach wrote:
> Am Donnerstag, den 24.07.2014, 17:17 +0800 schrieb Shawn Guo:
> > HDMI currently stops working after a system suspend/resume cycle. It
> > turns out that the cause is the imx-hdmi encoder .dpms hook doesn't get
> > called from anywhere
On Mon, Jun 09, 2014 at 10:44:14AM -0300, Fabio Estevam wrote:
> Russell,
>
> On Fri, Jun 6, 2014 at 10:56 AM, Russell King
> wrote:
> > The initial state at boot is assumed to be disconnected, and we hope
> > to receive an interrupt to update the status. Let's be more explicit
> > about the cur
On Mon, Jun 09, 2014 at 11:29:28AM -0300, Fabio Estevam wrote:
> On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux
> wrote:
>
> > Please check the status in /sys/class/drm/card0-HDMI-A-1/status. This
> > should report the current state of the hotplug detection.
>
On Mon, Jun 09, 2014 at 03:15:16PM -0300, Fabio Estevam wrote:
> With HDMI cable connected (no image is seen on HDMI, only on lvds cable):
>
> imx-drm display-subsystem.11: bound 12.hdmi (ops hdmi_ops)
> imx-hdmi 12.hdmi: EVENT=plugin
> imx-hdmi 12.hdmi: Non-CEA mode used in HDMI
> imx
On Mon, Jun 09, 2014 at 03:38:55PM -0300, Fabio Estevam wrote:
> On Mon, Jun 9, 2014 at 3:15 PM, Fabio Estevam wrote:
> >> I wonder if the problem is that HDMI and LVDS are interfering with each
> >> other wrt the required pixel clock, and LVDS is winning. If we have
> >> HDMI enabled, many HDMI
On Mon, Jun 09, 2014 at 03:47:46PM -0300, Fabio Estevam wrote:
> Also tested keeping LVDS parent as PLL5 and reverted this commit:
>
> commit 17b9b3b9e88ac6564689283a08034faf2c048fdb
> Author: Sascha Hauer
> Date: Mon Apr 14 16:20:39 2014 +0200
>
> ARM: imx6q: clk: Parent DI clocks to vide
On Tue, Jun 10, 2014 at 09:58:54AM -0300, Fabio Estevam wrote:
> Booting the kernel with the HDMI cable connected (no image is seen on
> HDMI, only on LVDS):
Reformatting a bit:
> disp 0: panel size = 1920 x 1080
> Clocks: IPU 26400Hz DI 2400Hz Needed 13850Hz
> IPU clock can give 13
On Tue, Jun 10, 2014 at 04:13:06PM +0100, Russell King - ARM Linux wrote:
> where 'M' is the IPU DI clock muxer. However, we're currently setting
> this up as:
>
> LM --+ LDB serial
> `- /7 -+ LDB DI clock
> IPM --- /N IM ---
On Tue, Jun 10, 2014 at 05:14:21PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 10, 2014 at 04:13:06PM +0100, Russell King - ARM Linux wrote:
> > where 'M' is the IPU DI clock muxer. However, we're currently setting
> > this up as:
> >
&
On Tue, Jun 10, 2014 at 10:32:25AM -0300, Fabio Estevam wrote:
> On Tue, Jun 10, 2014 at 9:58 AM, Fabio Estevam wrote:
> > On Mon, Jun 9, 2014 at 5:09 PM, Russell King - ARM Linux
> > wrote:
> >
> >> Right, so the problem isn't at the HDMI level, but at the
On Thu, Jun 12, 2014 at 04:05:32PM +0200, Arnd Bergmann wrote:
> This driver defines its own irqchip using the generic chip
> infrastructure, and hence needs the GENERIC_IRQ_CHIP Kconfig
> symbol enabled, or get this build error:
>
> drivers/built-in.o: In function `ipu_probe':
> :(.text+0x49ea4c)
On Thu, Jun 12, 2014 at 04:51:26PM +0200, Arnd Bergmann wrote:
> On Thursday 12 June 2014 15:23:54 Russell King - ARM Linux wrote:
> > On Thu, Jun 12, 2014 at 04:05:32PM +0200, Arnd Bergmann wrote:
> > > This driver defines its own irqchip using the generic chip
> > >
On Thu, Jun 12, 2014 at 06:00:07PM +0200, Arnd Bergmann wrote:
> On Thursday 12 June 2014 16:50:15 Russell King wrote:
> > DRM_PANEL_LD9040 and DRM_PANEL_S6E8AA0 both explicitly depended on
> > DRM_PANEL && DRM. This is nonsense for two reasons:
> >
> > (a) DRM_PANEL already depends on DRM, so DR
On Fri, Jun 13, 2014 at 07:54:45AM +0200, Andrzej Hajda wrote:
> Hi Russel,
>
> Thanks for both fixes. Just one nitpick.
>
> On 06/12/2014 06:09 PM, Russell King wrote:
> > DRM_PANEL_LD9040 and DRM_PANEL_S6E8AA0 both explicitly depended on
> > DRM_PANEL && DRM. This is nonsense for two reasons:
On Mon, Jun 16, 2014 at 12:11:15PM +0200, Denis Carikli wrote:
> That new macro is needed by the imx_drm staging driver
> for supporting the QVGA display of the eukrea-cpuimx51 board.
As I said probably around v10 time, I already have this patch queued,
and I was going to send it to Greg before
On Mon, Jun 16, 2014 at 12:11:16PM +0200, Denis Carikli wrote:
> Signed-off-by: Denis Carikli
> Acked-by: Philipp Zabel
As I said probably around v10 time, I already have this patch queued,
and I was going to send it to Greg before the previous merge window,
but due to the number of patches I wa
On Mon, Jun 16, 2014 at 12:11:17PM +0200, Denis Carikli wrote:
> The current BGR666 is not consistent with the other color mapings like BGR24.
> BGR666 should be in the same byte order than BGR24.
>
> Signed-off-by: Denis Carikli
> Acked-by: Philipp Zabel
As I said probably around v10 time, I a
On Mon, Jun 16, 2014 at 11:13:02AM -0300, Fabio Estevam wrote:
> On Wed, Jun 11, 2014 at 5:17 AM, Russell King - ARM Linux
> wrote:
>
> > The problem here is that we need more inteligence from CCF in order to
> > do that - we need it to be able to reprogram the dividers so
On Tue, Jun 24, 2014 at 06:54:26PM +0900, Alexandre Courbot wrote:
> From: Lucas Stach
>
> On architectures for which access to GPU memory is non-coherent,
> caches need to be flushed and invalidated explicitly at the
> appropriate places. Introduce two small helpers to make things
> easy for TTM
On Tue, Jun 24, 2014 at 09:23:05PM +0900, Alexandre Courbot wrote:
> On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot
> wrote:
> > The only alternative I see here is to flush the CPU caches when syncing for
> > the device, and invalidate them for the other direction. Of course if the
> > device
On Mon, Jun 16, 2014 at 12:11:20PM +0200, 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
This patch needs an ack from the
On Mon, Jun 16, 2014 at 12:11:19PM +0200, Denis Carikli wrote:
> The imx-drm driver can't use the de-active and
> pixelclk-active display-timings properties yet.
>
> Instead the data-enable and the pixel data clock
> polarity are hardcoded in the imx-drm driver.
>
> So theses properties are now s
Denis,
This patch creates binding documentation. Any patch which does so
should be copied to the DT people so they can review the bindings
and give appropriate acks. It would be better if you separate the
binding documentation updates from the other functional changes too.
I've added them on th
On Mon, Jun 16, 2014 at 12:11:18PM +0200, Denis Carikli wrote:
> Signed-off-by: Denis Carikli
It would be nice to have a little more explanation in the commit messages
for these patches. If you'd like to send me better commit messages for
these patches, I'll add them to what I already have:
On Tue, Jun 24, 2014 at 06:25:19PM +0200, Denis Carikli wrote:
> On 06/24/2014 05:13 PM, Russell King - ARM Linux wrote:
> [...]
>> If you'd like to send me better commit messages for
>> these patches, I'll add them to what I already have:
>
>> imx-drm: us
On Tue, Jun 17, 2014 at 11:17:03AM -0300, Guido Mart?nez wrote:
> Currently tda998x_encoder_destroy() calls cec_write() and reg_clear(),
> as part of the release procedure. Such calls need to access the I2C bus
> and therefore, we need to call them before drm_i2c_encoder_destroy()
> which unregiste
| 57 +---
include/linux/component.h | 8 +-
4 files changed, 208 insertions(+), 189 deletions(-)
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
On Wed, Jun 25, 2014 at 06:48:45AM +0200, Sascha Hauer wrote:
> On Mon, Jun 16, 2014 at 12:11:18PM +0200, Denis Carikli wrote:
> > +
> > /*
> > * Bitfield of Display Interface signal polarities.
> > */
> > @@ -37,7 +43,7 @@ struct ipu_di_signal_cfg {
> > unsigned clksel_en:1;
> > unsig
On Mon, Jun 16, 2014 at 12:11:21PM +0200, Denis Carikli wrote:
> The previous hardware behaviour was kept if the
> flags are not set.
I'd like to throw in a patch that I've been carrying for a bit now.
It conflicts with your patches, but I'm happy to fix that conflict
locally (and have been doing
On Tue, Jun 24, 2014 at 05:04:36PM -0500, Darren Etheridge wrote:
> On 06/17/2014 09:17 AM, Guido Mart?nez wrote:
>> Use module_init instead of late_initcall, as is the norm for modular
>> drivers.
>>
>> module_init was used until 6e8de0bd6a51fdeebd5d975c4fcc426f730b339b
>> ("drm/tilcdc: add encode
On Wed, Jun 25, 2014 at 02:00:42PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 24, 2014 at 05:04:36PM -0500, Darren Etheridge wrote:
> > On 06/17/2014 09:17 AM, Guido Mart?nez wrote:
> >> Use module_init instead of late_initcall, as is the norm for mo
On Wed, Jun 25, 2014 at 11:32:46AM -0300, Ezequiel Garc?a wrote:
> (Ccing Guido back)
>
> Hello Russell, Darren,
>
> On 25 Jun 02:00 PM, Russell King - ARM Linux wrote:
> > On Tue, Jun 24, 2014 at 05:04:36PM -0500, Darren Etheridge wrote:
> > > If I recall, the l
On Thu, Jun 26, 2014 at 02:34:17PM +0200, Philipp Zabel wrote:
> Hi Russell,
>
> On Tue, Jun 24, 2014 at 9:29 PM, Russell King
> wrote:
> [...]
> > +/*
> > + * Add a component to be matched.
> > + *
> > + * The match array is first created or extended if necessary.
> > + */
> > +void component_ma
On Thu, Jun 26, 2014 at 11:53:20PM +0900, Alexandre Courbot wrote:
> We don't plan to rely on CMA for too long. IOMMU support is on the way
> and should make our life easier, although no matter the source of
> memory, we will still have the issue of the lowmem mappings.
When it comes to DMA memory
On Wed, Jun 25, 2014 at 11:44:47AM +0200, Denis Carikli wrote:
> On 06/25/2014 06:48 AM, Sascha Hauer wrote:
>>> +#define ENABLE_POL_LOW 0
>>> +#define ENABLE_POL_HIGH1
>>
>> Adding defines without a proper namespace (IPU_) outside a driver
>> private header file is not nice
On Wed, Jul 31, 2013 at 10:21:20PM +0200, Sebastian Hesselbarth wrote:
> Should we prepare a new patch set comprising the following patches?
>
> Russell King:
> drm/i2c: nxp-tda998x: fix EDID reading on TDA19988 devices
> drm/i2c: nxp-tda998x: ensure VIP output mux is properly set
> drm/i2c: nxp-td
On Tue, Aug 06, 2013 at 12:20:12AM +0200, Sebastian Hesselbarth wrote:
> switch (mode) {
> case DRM_MODE_DPMS_ON:
> + /* Write the default value MUX register */
> + reg_write(encoder, REG_MUX_VP_VIP_OUT, 0x24);
This looks like an old version of my patch. I ende
On Tue, Aug 06, 2013 at 12:20:11AM +0200, Sebastian Hesselbarth wrote:
> From: Russell King
>
> TDA19988 devices need their RAM enabled in order to read EDID
> information. Add support for this.
>
> Signed-off-by: Russell King
> Tested-by: Sebastian Hesselbarth
There was some debate about wh
On Tue, Aug 06, 2013 at 12:20:15AM +0200, Sebastian Hesselbarth wrote:
> - also calculate CTS
This is wrong...
> + /*
> + * HDMI 1.3a, 7.2.2 CTS parameter:
> + * (avg cts) = (fTMDS * N) / (128 * fS)
> + */
> + cts = n * mode->clock / p->audio_sample_rate;
> + cts *= 10
On Tue, Aug 06, 2013 at 12:20:16AM +0200, Sebastian Hesselbarth wrote:
> + de_pix_s = mode->htotal - mode->hdisplay;
> + de_pix_e = de_pix_s + mode->hdisplay;
> + hs_pix_s = mode->hsync_start - mode->hdisplay;
> + hs_pix_e = hs_pix_s + mode->hsync_end - mode->hsync_s
On Tue, Aug 06, 2013 at 12:20:15AM +0200, Sebastian Hesselbarth wrote:
> @@ -0,0 +1,23 @@
> +#ifndef __TDA998X_H__
> +#define __TDA998X_H__
> +
> +enum tda998x_audio_format {
> + AFMT_I2S,
> + AFMT_SPDIF,
> +};
> +
> +struct tda998x_encoder_params {
> + int audio_cfg;
> + int audio_
On Tue, Aug 06, 2013 at 12:20:16AM +0200, Sebastian Hesselbarth wrote:
> This fixes the wrong sync generation and sync calculation of TDA998x
> for HS/VS-based sync detection.
>
> Signed-off-by: Sebastian Hesselbarth
The plus point with this is that interlaced modes (1080i) do work with
the TDA9
; drivers/gpu/drm/tilcdc/tilcdc_slave.c | 27 +-
> include/drm/i2c/tda998x.h | 30 ++
> 4 files changed, 467 insertions(+), 78 deletions(-)
> create mode 100644 include/drm/i2c/tda998x.h
>
> ---
> Cc: David Airlie
> Cc: Darren Etheridge
> Cc: Rob Clark
&g
On Mon, Aug 19, 2013 at 09:23:17AM +1000, Dave Airlie wrote:
> On Thu, Aug 15, 2013 at 5:43 AM, Sebastian Hesselbarth
> wrote:
> > From: Russell King
> >
> > This patch adds tda998x specific parameters to allow it to be configured
> > for different boards using it. Also, this implements rudimenta
On Wed, Aug 21, 2013 at 08:33:55PM +0200, Jean-Francois Moine wrote:
> On Wed Aug 14 12:43:30 PDT 2013, Sebastian Hesselbarth wrote:
> > +static void
> > +reg_write_range(struct drm_encoder *encoder, uint16_t reg, uint8_t *p, int
> > cnt)
> > +{
> > + struct i2c_client *client = drm_i2c_encoder_
On Wed, Aug 21, 2013 at 08:26:46PM +0200, Jean-Francois Moine wrote:
> On Wed Aug 14 12:43:29 PDT 2013, Sebastian Hesselbarth wrote:
> > From: Russell King
> >
> > The video-input-port (VIP) is highly configurable. This prepares
> > current driver to allow to configure VIP configuration, as some
On Thu, Aug 22, 2013 at 08:53:13AM +0200, Jean-Francois Moine wrote:
> On Wed, 21 Aug 2013 23:36:05 +0100
> Russell King - ARM Linux wrote:
>
> > > AFAIK, the TI boards have no "pin-swapped", nor has the Cubox (there is
> > > no need to set t
On Thu, Aug 22, 2013 at 07:33:43AM -0400, Rob Clark wrote:
> On Thu, Aug 22, 2013 at 2:53 AM, Jean-Francois Moine wrote:
> > On Wed, 21 Aug 2013 23:36:05 +0100
> > Russell King - ARM Linux wrote:
> >
> >> > AFAIK, the TI boards have no "pin-swapped", no
On Wed, Aug 14, 2013 at 09:43:30PM +0200, Sebastian Hesselbarth wrote:
> From: Russell King
>
> This patch adds tda998x specific parameters to allow it to be configured
> for different boards using it. Also, this implements rudimentary audio
> support for S/PDIF attached controllers.
>
> Signed-
| 48 +++-
drivers/usb/musb/tusb6010.c | 49 +++-
drivers/video/amba-clcd.c |5 ++
include/linux/amba/bus.h |2 -
include/linux/dma-mapping.h | 31 +
soun
On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote:
> Hi,
>
> On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
> > Use platform_device_register_full() for those drivers which can, to
> > avoid messing directly with DMA masks. This can only be done when
> > the driver does n
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote:
> On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
> > The correct way for a driver to specify the coherent DMA mask is
> > not to directly access the field in the struct device, but to use
> > dma_set_coherent_mask(). Only ar
On Fri, Sep 20, 2013 at 02:21:37AM +0100, Ben Hutchings wrote:
> On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote:
> [...]
> > -dma_set_coherent_mask() will always be able to set the same or a
> > -smaller mask as dma_set_mask(). However for the rare case that a
> > +The coherent coherent mask
On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote:
> Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
> > The DMA API requires drivers to call the appropriate dma_set_mask()
> > functions before doing any DMA mapping. Add this required call to
> > the AMBA PL08x driver
Ping?
On Mon, Sep 02, 2013 at 03:50:57PM +0100, Russell King - ARM Linux wrote:
> On Wed, Aug 14, 2013 at 09:43:30PM +0200, Sebastian Hesselbarth wrote:
> > From: Russell King
> >
> > This patch adds tda998x specific parameters to allow it to be configured
> > fo
On Mon, Sep 23, 2013 at 03:55:33PM +0530, Vinod Koul wrote:
> On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
> > register_platform_device_full() can setup the DMA mask provided the
> > appropriate member is set in struct platform_device_info. So lets
> > make that be the case. This
On Mon, Sep 23, 2013 at 02:27:39PM -0400, Alan Stern wrote:
> On Thu, 19 Sep 2013, Russell King wrote:
>
> > The correct way for a driver to specify the coherent DMA mask is
> > not to directly access the field in the struct device, but to use
> > dma_set_coherent_mask(). Only arch and bus code s
On Thu, Sep 26, 2013 at 09:51:23AM +0200, Takashi Iwai wrote:
> Hi,
>
> sorry for the lat response, as I've been traveling in the last weeks.
>
> At Thu, 19 Sep 2013 22:53:02 +0100,
> Russell King wrote:
> >
> > This code sequence is unsafe in modules:
> >
> > static u64 mask = DMA_BIT_MASK(som
On Thu, Sep 26, 2013 at 04:21:36PM +0530, Archit Taneja wrote:
> Hi,
>
> On Friday 20 September 2013 04:41 AM, Russell King wrote:
>> The correct way for a driver to specify the coherent DMA mask is
>> not to directly access the field in the struct device, but to use
>> dma_set_coherent_mask(). On
On Thu, Sep 26, 2013 at 10:23:08PM +0200, Rafał Miłecki wrote:
> 2013/9/19 Russell King - ARM Linux :
> > This email is only being sent to the mailing lists in question, not to
> > anyone personally. The list of individuals is far to great to do that.
> > I'm hoping n
by: Russell King
Airlied, can you merge this please? Thanks.
> Thanks
> David
>
> > ---
> >
> > Hi,
> >
> > This can be seen with e.g. linux next-20140523 and arm allmodconfig.
> >
> > Best regards,
> >
> > V.
> >
>
On Sun, May 25, 2014 at 02:34:09PM +0200, David Herrmann wrote:
> shmem_read_mapping_page() uses mapping_gfp_mask(mapping) as default gfp
> mask. No reason to use shmem_read_mapping_page_gfp() directly if we want
> the default behavior.
>
> Cc: Russell King
> Signed-off-by: David Herrmann
Nothi
On Tue, Nov 04, 2014 at 09:33:10PM +0800, Andy Yan wrote:
> From: Andy yan
>
> We found freescale imx6 and rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS)
> use the interface compatible Designware HDMI IP, but they also have some
> lightly difference, such as phy pll configuration, register widt
On Wed, Nov 05, 2014 at 02:25:12PM +0100, Thierry Reding wrote:
> Discussion on IRC lead to the conclusion that new IOCTLs should have
> input validation and require userspace to zero out output parameters to
> avoid this kind of mess in the future. In order to help avoid this kind
> of ambiguity i
On Wed, Nov 05, 2014 at 08:47:07PM +0200, Laurent Pinchart wrote:
> (On a side note I believe treating the pitch and size arguments as inputs
> could be a worthwhile extension to the API, but given that we haven't
> rejected incorrect values in the past we're pretty much stuck).
The bigger pictur
me(struct device *dev)
+{
+ struct snd_dw_hdmi *dw = dev_get_drvdata(dev);
+
+ snd_power_change_state(dw->card, SNDRV_CTL_POWER_D0);
+
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(snd_dw_hdmi_pm, snd_dw_hdmi_suspend,
+snd_dw_hdmi_resume);
+#define PM_OPS &am
On Sat, Nov 15, 2014 at 06:07:50PM +0800, Daniel Kurtz wrote:
> On Fri, Nov 14, 2014 at 7:13 PM, Zubair Lutfullah Kakakhel
> wrote:
> >
> >
> > On 14/11/14 11:08, Andy Yan wrote:
> >>
> >> On 2014å¹´11æ14æ¥ 18:55, Zubair Lutfullah Kakakhel wrote:
> >>>
> >>> On 14/11/14 10:53, Andy Yan wrote:
>
On Sat, Nov 15, 2014 at 10:12:18AM +, Russell King - ARM Linux wrote:
> Once the wranglings on the patch series are complete, I do intend to test
> it on the platforms I have - and remember that I do have the ALSA based
> audio and CEC bits as well, some of which will probably need
On Tue, Nov 18, 2014 at 05:39:30PM +, Andrew Jackson wrote:
> On HDMI, the audio data are carried across the HDMI link which is
> driven by the TDMS clock. The TDMS clock is dependent on the video pixel
> rate.
>
> This patch sets the denominator (Cycle Time Stamp) appropriately
> allowing the
On Fri, Aug 26, 2016 at 04:25:13PM +0200, Marek Vasut wrote:
> The content of gpu->memory_base should point to start of RAM, not zero.
>
> Signed-off-by: Marek Vasut
> Cc: Lucas Stach
> Cc: Christian Gmeiner
> Cc: Russell King
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 ++
> 1 file cha
401 - 500 of 1611 matches
Mail list logo
