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
g is_vmalloc_addr(). Unless callers have special reasons, we can
> replace this branch with kvfree(). Please check and reply if you found
> problems.
>
> Signed-off-by: Tetsuo Handa
> Acked-by: Michal Hocko
> Cc: Russell King # arm
Acked-by: Russell King
In so far as this
>
> Drop the now unused custom imx_drm_get_port_by_id function.
>
> Signed-off-by: Philipp Zabel
> Suggested-by: Russell King
Yay, many thanks for this, Philipp! For patches 3 and 4:
Acked-by: Russell King
(Please change to use rmk+kernel in both Suggested-by lines as well.)
I
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
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()
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/g
On Fri, Jun 03, 2016 at 10:29:40AM -0500, Rob Herring wrote:
> On Fri, Jun 3, 2016 at 9:21 AM, Russell King
> wrote:
> > Add common OF-based component functionality for matching devices by
> > device node, and releasing the device node at the appropraite time.
> >
> &g
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 de
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
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
>
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
allows us to have it in a single place for
> both cases.
>
> This also shaves off quite a bit of the CPU time spent in hardirq
> context, as arming the autosuspend timer when the RPM refcount
> drops to 0 is a relatively costly operation.
>
> Signed-off-by: Lucas Stach
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
On Tue, Jan 26, 2016 at 05:59:13PM +, Jon Medhurst (Tixy) wrote:
> I believe I've found a problem with the component helpers and/or how
> drivers use them. I discovered this whilst trying to get ARM's HDLCD
> driver [1] working on 4.5-rc1, however I believe that code is following
> a pattern us
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
On Sun, Jul 13, 2014 at 12:19:03PM +0100, Russell King wrote:
> drivers/gpu/drm/shmobile/shmob_drm_drv.c:300:5: warning: "CONFIG_PM_SLEEP" is
> not defined [-Wundef]
>
> Always use #ifdef with CONFIG symbols, never just bare #if
>
> Signed-off-by: Russell King
Pin
On Sun, Jul 13, 2014 at 12:18:58PM +0100, Russell King wrote:
> drivers/gpu/drm/rcar-du/rcar_du_drv.c:190:5: warning: "CONFIG_PM_SLEEP" is
> not defined [-Wundef]
>
> Always use #ifdef with CONFIG symbols, never just bare #if
>
> Signed-off-by: Russell King
Pin
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 b
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
: Parent DI clocks to video PLL via di_pre_sel
>
> Route the video PLL to the display interface clocks via the di_pre_sel
> and di_sel muxes by default.
>
> Signed-off-by: Sascha Hauer
> Signed-off-by: Philipp Zabel
> Tested-by: Russell King
> Sig
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) D
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
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
A while back, Laurent raised some comments about the component helper,
which this patch set starts to address.
The first point it addresses is the repeated parsing inefficiency when
deferred probing occurs. When DT is used, the structure of the
component helper today means that masters end up par
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
cation of
the current code, and allows better decisions about things like clk_pol
to be made.
I'm sending it here because it is relevent to Denis' patch set - I will
also send it out separately if people want it separately, though that
will go to a reduced Cc list.
From: Russell King
Subj
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 ex
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
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
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
or v2, too.
>
> I have not added Russell King's Tested-by, as I hope he will have a
> close look at what I changed after his review comments.
>
> Darren Etheridge (1):
> drm/tilcdc fixup mode to workaround sync for tda998x
>
> Russell King (5):
> drm/i2c: tda998x
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 u
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
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 controlle
This started out as a request to look at the DMA mask situation, and how
to solve the issues which we have on ARM - notably how the DMA mask
should be setup.
However, I started off reviewing how the dma_mask and coherent_dma_mask
was being used, and what I found was rather messy, and in some cases
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 whe
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_c
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
> >
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
>
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
> >
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().
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:
>
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
>
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
6: error: macro "dma_buf_export"
> > requires 5 arguments, but only 4 given
> >
> > Signed-off-by: Vincent Stehl?
> > Cc: Russell King
> > Cc: David Airlie
> > Cc: Maarten Lankhorst
> > Cc: Sumit Semwal
>
> Reviewed-by: David Herrmann
Acked-
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-
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
on the CEC bus, you
need the logical ID arbitration to work properly.)
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
-- next part --
From: Russell King
Subject: [PATCH 018/107] dw-hdmi-audio: add audio driver
MIME-Ver
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/etn
On Fri, Aug 26, 2016 at 05:53:38PM +0200, Lucas Stach wrote:
> Sorry, please ignore the FEC patches. Those are test patches still
> residing in my to-send folder. Sorry for the noise.
This patch actually looks correct: you are indeed correct that the
driver can end up with a packet sitting waiting
On Fri, Aug 26, 2016 at 05:49:54PM +0200, Lucas Stach wrote:
> The devicetree documentation states that those are required properties,
> so the driver should refuse to probe if those are absent to be
> consistent. This will also allow to drop some error checking from the
> clock enable/disable path
ssel King
That's "Russell King" please.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
On Mon, Aug 29, 2016 at 12:47:20PM +0200, Lucas Stach wrote:
> Core, bus and shader are all module input clocks. If the SoC integration
> provides the same clock for all inputs, the DT should reflect this by
> supplying the same clock for all 3 inputs.
You're making an assertion that we don't know
901 - 1000 of 2033 matches
Mail list logo
