On Sat, Oct 11, 2014 at 10:26:20AM +0100, Russell King - ARM Linux wrote:
> Daniel,
>
> A while back you had a go at fixing the framebuffer reference counting.
> Unfortunately, I'm still seeing leaks, particularly with the framebuffer
> used with a mode set which is subseque
On Mon, Oct 27, 2014 at 11:26:30PM +0100, Daniel Vetter wrote:
> Looking at the of_drm_find_panel function I actually wonder how that
> works - the drm_panel doesn't really need to stick around afaics.
> After all panel_list is global so some other driver can unload.
> Russell's of support for poss
And another issue...
What is drm_crtc_helper_set_mode() passed as the fb argument? Is it
the old fb, or the new fb?
bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
struct drm_display_mode *mode,
int x, int y,
On Thu, Jun 13, 2013 at 12:19:03PM +0100, Russell King - ARM Linux wrote:
> The deeper I look, the more bugs there seem to be in this DRM stuff,
> and I'm continuing to look because I'm chasing a framebuffer refcount
> bug.
So, this refcount bug - I think I've just found
On Thu, Jun 13, 2013 at 12:50:16PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jun 13, 2013 at 12:19:03PM +0100, Russell King - ARM Linux wrote:
> > The deeper I look, the more bugs there seem to be in this DRM stuff,
> > and I'm continuing to look because I'm chasi
gt; 4. Now CPU or DMA can access all dmabufs locked in step 3.
>
> 5. Unlock all dmabufs added in a sync object after DMA or CPU access
> to these dmabufs is completed:
> dmabuf_sync_unlock(sync);
>
> And call the following functions to release all resource
On Fri, Jun 14, 2013 at 03:53:41PM +0200, Daniel Vetter wrote:
> On Thu, Jun 13, 2013 at 12:50:16PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Jun 13, 2013 at 12:19:03PM +0100, Russell King - ARM Linux wrote:
> > > The deeper I look, the more bugs there seem to be
On Fri, Jun 14, 2013 at 04:23:22PM +0200, Daniel Vetter wrote:
> On Thu, Jun 13, 2013 at 3:03 PM, Russell King - ARM Linux
> wrote:
> > There's a bigger issue here - if it's possible for
> > drm_crtc_helper_set_config()
> > to be called with set->fb set
On Fri, Jun 14, 2013 at 09:50:22PM +0200, Daniel Vetter wrote:
> On Fri, Jun 14, 2013 at 4:42 PM, Russell King - ARM Linux
> wrote:
> > If you're happy with the patch I supplied, that's probably the minimal fix
> > which should go to stable kernels (I'm using 3.9
On Mon, Jun 17, 2013 at 10:04:45PM +0900, Inki Dae wrote:
> It's just to implement a thin sync framework coupling cache operation. This
> approach is based on dma-buf for more generic implementation against android
> sync driver or KDS.
>
> The described steps may be summarized as:
> lock ->
On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
> 2013/6/17 Russell King - ARM Linux
> Exactly right. But that is not definitely my point. Could you please see
> the below simple example?:
> (Presume that CPU and DMA share a buffer and the buffer is mapped with user
> sp
On Mon, Jun 17, 2013 at 04:42:37PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
> > 2013/6/17 Russell King - ARM Linux
> > Exactly right. But that is not definitely my point. Could you please see
> > the below simple e
On Tue, Jun 18, 2013 at 02:19:04AM +0900, Inki Dae wrote:
> It seems like that all pages of the scatterlist should be mapped with
> DMA every time DMA operation is started (or drm_xxx_set_src_dma_buffer
> function call), and the pages should be unmapped from DMA again every
> time DMA operation is
On Tue, Jun 18, 2013 at 02:27:40PM +0900, Inki Dae wrote:
> So I'd like to ask for other DRM maintainers. How do you think about it? it
> seems like that Intel DRM (maintained by Daniel), OMAP DRM (maintained by
> Rob) and GEM CMA helper also have same issue Russell pointed out. I think
> not only
On Tue, Jun 18, 2013 at 06:04:44PM +0900, Inki Dae wrote:
>
>
> > -Original Message-
> > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> > Sent: Tuesday, June 18, 2013 5:43 PM
> > To: Inki Dae
> > Cc: 'Maarten Lankhorst'
On Tue, Jun 18, 2013 at 09:00:16AM +0200, Daniel Vetter wrote:
> On Mon, Jun 17, 2013 at 04:42:37PM +0100, Russell King - ARM Linux wrote:
> > What we need is something along the lines of:
> > (a) dma_buf_map_attachment() _not_ to map the scatterlist for DMA.
> > or
> &g
On Thu, Jun 20, 2013 at 12:10:04AM +0900, Inki Dae wrote:
> On the other hand, the below shows how we could enhance the conventional
> way with my approach (just example):
>
> CPU -> DMA,
> ioctl(qbuf command) ioctl(streamon)
> |
evel-bounces+inki.dae=samsung.com at lists.freedesktop.org]
> > > On
> > > Behalf Of Russell King - ARM Linux
> > > Sent: Thursday, June 20, 2013 3:29 AM
> > > To: Inki Dae
> > > Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myun
On Thu, Jun 20, 2013 at 09:46:03PM +0200, Sebastian Hesselbarth wrote:
> + ref_pix = 3 + mode->hsync_start - mode->hdisplay;
> + de_pix_s = mode->htotal - mode->hdisplay;
> + de_pix_e = de_pix_s + mode->hdisplay;
> + hs_pix_s = mode->hsync_start - mode->hdisplay;
>
On Wed, Jun 26, 2013 at 06:42:50PM +0200, Jean-Francois Moine wrote:
> Do you know that there are 2 drm drivers for the Cubox? I posted mine
> (http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/168732.html)
> before Russell, but I got no return about it yet.
>
> As
On Tue, Jun 25, 2013 at 11:23:21AM +0200, Daniel Vetter wrote:
> Just a quick question on your assertion that we need all four
> functions: Since we already have begin/end_cpu_access functions
> (intention here was to allow the dma_buf exporter to ensure the memory
> is pinned, e.g. for swapable ge
On Tue, Jun 25, 2013 at 04:47:26PM -0400, Daniel Drake wrote:
> Hi Russell,
>
> Thanks a lot for writing the Armada DRM driver.
>
> I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3
> aka PXA2128). After a bit of fighting, I have it running. Could you share your
> X driver
On Fri, Jun 28, 2013 at 01:54:21PM -0600, Daniel Drake wrote:
> On Wed, Jun 26, 2013 at 10:42 AM, Jean-Francois Moine
> wrote:
> > Do you know that there are 2 drm drivers for the Cubox? I posted mine
> > (http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/16873
&priv->linear);
> err_buf:
> @@ -193,6 +210,7 @@ static int armada_drm_unload(struct drm_device *dev)
> drm_irq_uninstall(dev);
> drm_mode_config_cleanup(dev);
> drm_mm_takedown(&priv->linear);
> + release_clocks(priv);
> dev->dev_private = NULL;
>
> return 0;
> diff --git a/drivers/gpu/drm/armada/armada_hw.h
> b/drivers/gpu/drm/armada/armada_hw.h
> index 58d2a20..df59b5a 100644
> --- a/drivers/gpu/drm/armada/armada_hw.h
> +++ b/drivers/gpu/drm/armada/armada_hw.h
> @@ -193,11 +193,12 @@ enum {
> };
>
> /* For LCD_CFG_SCLK_DIV */
> +#define SCLK_510_SHIFT 30
> enum {
> - SCLK_510_AXI= 0x0 << 30,/* Armada 510 */
> - SCLK_510_EXTCLK0= 0x1 << 30,/* Armada 510 */
> - SCLK_510_PLL= 0x2 << 30,/* Armada 510 */
> - SCLK_510_EXTCLK1= 0x3 << 30,/* Armada 510 */
> + SCLK_510_AXI= 0x0 << SCLK_510_SHIFT,/* Armada 510 */
> + SCLK_510_EXTCLK0= 0x1 << SCLK_510_SHIFT,/* Armada 510 */
> + SCLK_510_PLL= 0x2 << SCLK_510_SHIFT,/* Armada 510 */
> + SCLK_510_EXTCLK1= 0x3 << SCLK_510_SHIFT,/* Armada 510 */
> SCLK_DIV_CHANGE = 1 << 29,
> SCLK_16X_AHB= 0x0 << 28,/* Armada 16x */
> SCLK_16X_PCLK = 0x1 << 28,/* Armada 16x */
> --
> 1.8.1.4
>
> ___
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Fri, Jun 28, 2013 at 10:18:48PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jun 28, 2013 at 04:11:32PM -0400, Daniel Drake wrote:
> > +int armada_drm_find_best_clock(struct armada_private *priv, long
> > needed_rate)
> > +{
> > + int i;
> > +
> >
On Tue, Jun 25, 2013 at 04:47:26PM -0400, Daniel Drake wrote:
> I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3
> aka PXA2128). After a bit of fighting, I have it running. Could you share your
> X driver, or your methodology for testing hardware cursors? I'd like to test
>
On Fri, Jun 28, 2013 at 03:36:37PM -0600, Daniel Drake wrote:
> On Fri, Jun 28, 2013 at 3:27 PM, Russell King - ARM Linux
> wrote:
> > On Tue, Jun 25, 2013 at 04:47:26PM -0400, Daniel Drake wrote:
> >> I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (
On Sat, Jun 29, 2013 at 05:58:26PM +0200, Sebastian Hesselbarth wrote:
> On 06/29/2013 05:06 PM, Daniel Drake wrote:
>> On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
>> wrote:
>>> Sure... lets add some background info first: the big problem here is the
hough I have the 16x specs, I don't have hardware for it, and I
haven't spent that long digging in to it.
> So, could we just specify per-CRTC clock preference in platform data,
> DT, or something like that? e.g. we could just specify which SCLK bits
> to set and clear, and whi
Quite a number of things has changed since the last revision in the
core code - notably the move to use drm_plane for overlay, and the
limited and restricted use of dma_buf so that gem objects can be
passed to the GALCORE code and libbmm contiguous video frames can
be imported into DRM.
As I thoug
On Sun, Jun 30, 2013 at 01:59:41PM +0200, Daniel Vetter wrote:
> On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
> > +static uint32_t armada_drm_crtc_calculate_csc(struct armada_crtc *dcrtc)
> > +{
> > + struct drm_display_mode *adj = &dcrtc->crtc.mode;
> > + uint32_t val = 0;
> >
On Sun, Jun 30, 2013 at 02:37:41PM +0200, Daniel Vetter wrote:
> On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
> > + mutex_lock(&dev->struct_mutex);
> > + free = drm_mm_search_free(&priv->linear, size, align, 0);
> > + if (free)
> > +
On Sun, Jun 30, 2013 at 02:04:56PM +0100, Russell King - ARM Linux wrote:
> On Sun, Jun 30, 2013 at 02:37:41PM +0200, Daniel Vetter wrote:
> > On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
> > > + mutex_lock(&dev->struct_mutex);
> > > +
Right, so, incrementally, the changes are (this may not entirely apply
to the version I've posted because I have several patches on top of
that.)
I've also added locking to the calls to drm_mm_dump_table() as otherwise
these walk those lists without holding any locks what so ever, which
could mean
On Mon, Jul 01, 2013 at 10:01:30AM +1000, Dave Airlie wrote:
> OMG I'm working in a subsystem where stuff is being developed, with only
> a few resources! I know my full time job isn't maintaining a 500,000
> line subsystem,
> and the sub maintainers and developers do a great job refactoring
> wher
On Tue, Jan 26, 2021 at 06:56:52PM +0100, Uwe Kleine-König wrote:
> I'm surprised to see that the remove callback introduced in 2952ecf5df33
> ("coresight: etm4x: Refactor probing routine") has an __exit annotation.
In general, remove callbacks should not have an __exit annotation.
__exit _can_ be
On Tue, Jan 26, 2021 at 05:58:30PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
> Hello,
>
> Changes since v2 sent with Message-Id:
> 20201124133139.3072124-1-...@kleine-koenig.org:
>
> - Rebase to v5.11-rc1 (which resulted in a few conflicts in
>drivers/hwtracing).
> - Add var
On Tue, Feb 02, 2021 at 03:06:05PM +0100, Greg Kroah-Hartman wrote:
> I'm glad to take this through my char/misc tree, as that's where the
> other coresight changes flow through. So if no one else objects, I will
> do so...
Greg, did you end up pulling this after all? If not, Uwe produced a v2.
I
On Thu, Feb 04, 2021 at 05:56:50PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Feb 04, 2021 at 04:52:24PM +, Russell King - ARM Linux admin
> wrote:
> > On Tue, Feb 02, 2021 at 03:06:05PM +0100, Greg Kroah-Hartman wrote:
> > > I'm glad to take this through my char/
On Sat, May 08, 2021 at 12:41:18AM -0700, Stephen Boyd wrote:
> Within the component device framework this usually isn't that bad
> because the real driver work is done at bind time via
> component{,master}_ops::bind(). It becomes a problem when the driver
> core, or host driver, wants to operate o
On Mon, May 10, 2021 at 06:05:21PM +0200, Daniel Vetter wrote:
> Entirely aside, but an s/master/aggregate/ or similar over the entire
> component.c codebase would help a pile in making it easier to understand
> which part does what. Or at least I'm always terribly confused about which
> bind binds
On Sun, Nov 08, 2020 at 10:53:22AM +0100, Sam Ravnborg wrote:
> Russell,
>
> On Sat, Oct 31, 2020 at 07:17:47PM +1100, Jonathan Liu wrote:
> > It has been observed that resetting force in the detect function can
> > result in the PHY being powered down in response to hot-plug detect
> > being asse
Ping.
On Mon, Feb 25, 2019 at 10:54:23AM +, Russell King - ARM Linux admin wrote:
> On Mon, Feb 25, 2019 at 10:51:30AM +, Russell King wrote:
> > During boot, I get this kernel warning:
> >
> > WARNING: CPU: 0 PID: 19001 at kernel/dma/debug.c:1301
> > d
On Sat, May 18, 2019 at 06:04:42PM -0300, Fabio Estevam wrote:
> Hi Russell,
>
> On Sat, May 18, 2019 at 2:51 PM Russell King - ARM Linux admin
> wrote:
> >
> > Ping.
>
> This patch is present in Lucas' pull request:
> https://lists.freedesktop.org/arch
Hi Lucas,
Seems I'm not getting a reply, so I'm hijacking one of your more
recent patches in the hope of attracting your attention.
A while back I sent a fix for a regression that recently occurred
with etnaviv, where the kernel spat out a warning when importing
buffers into etnaviv. You apparen
On Wed, May 22, 2019 at 12:04:27PM +0200, Lucas Stach wrote:
> Hi Russell,
>
> Am Samstag, den 18.05.2019, 22:37 +0100 schrieb Russell King - ARM
> Linux admin:
> > On Sat, May 18, 2019 at 06:04:42PM -0300, Fabio Estevam wrote:
> > > Hi Russell,
> > >
&
On Wed, May 22, 2019 at 11:55:14AM +0200, Lucas Stach wrote:
> The devcoredump needs to operate on a stable state of the MMU while
> it is writing the MMU state to the coredump. The missing lock
> allowed both the userspace submit, as well as the GPU job finish
> paths to mutate the MMU state while
| 6 +-
> .../common/videobuf2/videobuf2-dma-contig.c | 6 +-
> .../media/common/videobuf2/videobuf2-dma-sg.c | 6 +-
> drivers/misc/fastrpc.c | 6 +-
> drivers/staging/media/tegra-vde/tegra-vde.c | 6 +++++-
>
gt; > the
> > > > + framebuffer
> > > > +
> > > > +Example:
> > > > +
> > > > + display-subsystem {
> > > > + compatible = "marvell,dove-display-subsystem",
> > > > +
On Mon, Jan 21, 2019 at 09:45:22PM +0100, Lubomir Rintel wrote:
> On Mon, 2019-01-21 at 17:53 +, Russell King - ARM Linux admin
> wrote:
> > On Mon, Jan 21, 2019 at 10:07:11AM -0600, Rob Herring wrote:
> > > On Mon, Jan 21, 2019 at 9:46 AM Lubomir Rintel wrote:
> >
On Mon, Jan 21, 2019 at 05:58:50PM -0600, Rob Herring wrote:
> On Mon, Jan 21, 2019 at 11:53 AM Russell King - ARM Linux admin
> wrote:
> >
> > On Mon, Jan 21, 2019 at 10:07:11AM -0600, Rob Herring wrote:
> > > On Mon, Jan 21, 2019 at 9:46 AM Lubomir Rintel wrote:
>
On Mon, Jan 21, 2019 at 07:01:57AM +0100, Lubomir Rintel wrote:
> If there's a simple-framebuffer carried over from boot firmware, it's going
> to stop working once we setup the LCDC for use via DRM. Kick it off from
> the hardware.
Applied, thanks.
>
> Signed-off-by: Lubomir Rintel
> ---
> dr
On Mon, Jan 21, 2019 at 07:03:49AM +0100, Lubomir Rintel wrote:
> Heavily based on the Armada 510 (Dove) support. Like with 510 support, this
> also just supports a single source clock -- the "Display 1" clock as
> generated by the APMU. This one was chosen because the OLPC XO 1.75 laptop
> uses it
Hi,
This series adds support for programming the SPD and vendor infoframes.
It also adds support for pixel repeated modes - we were not rejecting
these modes, but we also didn't have the implementation to support
them. As their implementation is simple, add it rather than rejecting
the modes.
S
(Removed what I assume is a typo on the Cc line - n...@arm.com)
On Fri, Jan 25, 2019 at 11:45:10AM +, Brian Starkey wrote:
> Hi Russell,
>
> On Fri, Jan 25, 2019 at 09:40:38AM +, Russell King - ARM Linux admin
> wrote:
> > Hi,
> >
> > This series adds s
On Wed, Jan 30, 2019 at 03:41:04PM +, Brian Starkey wrote:
> Hi Russell,
>
> These did eventually reach me on Saturday evening.
>
> On Fri, Jan 25, 2019 at 09:43:19AM +, Russell King wrote:
> > Add support for writing the SPD infoframe to the TDA998x. Identify us
> > as "Generic" vendor
On Wed, Jan 30, 2019 at 03:53:04PM +, Brian Starkey wrote:
> Hi Russell,
>
> On Fri, Jan 25, 2019 at 09:43:29AM +, Russell King wrote:
> > CEA-861 says: "A Source shall not send a non-zero Q value that does
> > not correspond to the default RGB Quantization Range for the
> > transmitted Pi
cumentation/driver-api/device_link.rst | 3 +
> Documentation/driver-api/index.rst | 1 +
> drivers/base/component.c | 107 ++-
> include/linux/component.h| 70 +++
> 5 files changed, 195 insertions(+), 3 deletions(-)
> c
> Cc: Russell King
> Cc: Rafael J. Wysocki
> Cc: Jaroslav Kysela
> Cc: Takashi Iwai
> Cc: Rodrigo Vivi
> Cc: Jani Nikula
> Signed-off-by: Daniel Vetter
> ---
> drivers/base/component.c | 158 +-
> include/linux/component.h | 10
On Tue, Dec 18, 2018 at 04:37:26PM +0100, Lubomir Rintel wrote:
> here are patches that make the Armada DRM work on an OLPC XO-1.75.
> They build on patches previously submitted by Russel King (included here for
> completeness as well).
Hi,
Would it be possible for you to re-post patches 1 throug
On Tue, Dec 18, 2018 at 04:37:40PM +0100, Lubomir Rintel wrote:
> It needs to be enabled (at least on MMP2) in order for the register
> writes to LCDC to work.
Dove also has an AXI clock input to the LCDC, but it isn't clear
whether that is necessary for register access or not. From a quick
searc
On Thu, Jan 17, 2019 at 04:03:45PM +0100, Lubomir Rintel wrote:
> On Thu, 2019-01-17 at 10:55 +, Russell King - ARM Linux admin
> wrote:
> > On Tue, Dec 18, 2018 at 04:37:26PM +0100, Lubomir Rintel wrote:
> > > here are patches that make the Armada DRM work on an OLPC XO-1
d event, then, because we
create them during probe, we'll be attempting to recreate the link
when we reattach the supplier to the consumer. If we only allow one
instance, then what does device_link_add() return.
Maybe it is going to be less painful to push everything bridge-related
to us
On Thu, Feb 21, 2019 at 01:18:13PM -0500, Sven Van Asbroeck wrote:
> My cpu dai driving the tda998x in master mode outputs
> SNDRV_PCM_FORMAT_S24_LE, i2s left justified, two channels:
>
> [SNDRV_PCM_FORMAT_S24_LE] = {
> .width = 24, .phys = 32, .le = 1, .signd = 1,
>
On Fri, Feb 22, 2019 at 03:47:14PM +0200, Peter Ujfalusi wrote:
> Hi,
>
> the original version was sent 14.04.2018:
> https://patchwork.kernel.org/patch/10344403/
>
> Changes since then:
> - rebased on currentl drm/next
>
> The reset value of the register is 0, the soft reset does not reset this
On Fri, Feb 22, 2019 at 05:20:15PM +0200, Peter Ujfalusi wrote:
> Hi Russell,
>
> On 22/02/2019 16.35, Russell King - ARM Linux admin wrote:
> > On Fri, Feb 22, 2019 at 03:47:14PM +0200, Peter Ujfalusi wrote:
> >> Hi,
> >>
> >> the origin
On Fri, Feb 22, 2019 at 05:20:15PM +0200, Peter Ujfalusi wrote:
> > and I think we should implement at least setting the I2S
> > register format from the hdmi_codec_daifmt data.
>
> Yes, that needs to be done for sure, but without data sheet with
> register descriptions I would not attempt to do t
(Adding Mark, ASoC maintainer.)
On Fri, Feb 22, 2019 at 10:47:35AM -0500, Sven Van Asbroeck wrote:
> On Fri, Feb 22, 2019 at 8:21 AM Russell King - ARM Linux admin
> wrote:
> >
> > On Thu, Feb 21, 2019 at 01:18:13PM -0500, Sven Van Asbroeck wrote:
> >
> > &g
On Fri, Feb 22, 2019 at 03:27:43PM +, Russell King - ARM Linux admin wrote:
> On Fri, Feb 22, 2019 at 05:20:15PM +0200, Peter Ujfalusi wrote:
> > Hi Russell,
> >
> > On 22/02/2019 16.35, Russell King - ARM Linux admin wrote:
> > > It would also be good to know
On Fri, Feb 22, 2019 at 04:27:35PM +, Russell King - ARM Linux admin wrote:
> On Fri, Feb 22, 2019 at 10:47:35AM -0500, Sven Van Asbroeck wrote:
> > The config structure which you need to fill in to init the audio has a
> > "i2s qualifier" field, where you have the
This series addresses two issues with TDA998x that have been
identified:
1) Peter found that the I2S format was not being explicitly set, and
retains its value from whatever was previously running on the
platform. Work around this by implementing support for setting
the I2S format from t
On Fri, Feb 22, 2019 at 04:18:33PM -0500, Sven Van Asbroeck wrote:
> Russell, thank you so much for your patience, help and explanation, I really
> appreciate it !
>
> Yes, that would keep the current users in business without them having to
> change anything.
>
> Of course, poor souls like mysel
__do_softirq+0x344/0x540
> softirqs last disabled at (47701): [] irq_exit+0x124/0x144
> ---[ end trace af477747acbcc642 ]---
>
> The reason is the contiguous buffer exceeds the default maximum segment
> size of 64K as specified by dma_get_max_seg_size() in
> linux/dma-mapping.h
On Mon, Feb 25, 2019 at 03:28:51PM +0200, Peter Ujfalusi wrote:
> hi Russell,
>
> On 22/02/2019 23.27, Russell King wrote:
> > Add support for the left and right justified I2S formats as well as the
> > more tranditional "Philips" I2S format.
>
> First of all, thank you for the patch, it works.
>
On Tue, Feb 26, 2019 at 09:35:47AM +0900, Kuninori Morimoto wrote:
> > @@ -97,7 +98,7 @@ static int asoc_simple_card_hw_params(struct
> > snd_pcm_substream *substream,
> > struct simple_card_data *priv = snd_soc_card_get_drvdata(rtd->card);
> > struct simple_dai_props *dai_props =
> >
[51329.353376] [ cut here ]
[51329.358004] kernel BUG at /home/rmk/git/linux-rmk/mm/vmalloc.c:1612!
[51329.364365] Internal error: Oops - BUG: 0 [#1] SMP ARM
[51329.369510] Modules linked in: ip6t_REJECT nf_reject_ipv6 ip6t_rpfilter
xt_tcpudp ipt_REJECT nf_reject_ipv4 xt_connt
On Tue, Feb 26, 2019 at 09:53:22AM -0500, Sven Van Asbroeck wrote:
> I notice that hdmi-codec.c supports up to 8 channels in hdmi multi-channel
> playback mode. If we had a _theoretical_ hdmi xmitter with 8chan support,
> would the bclk_ratio not be 8 x slot_size - or 8 x 32 if using an fsl_ssi
> i
On Tue, Feb 26, 2019 at 11:31:15AM -0500, Sven Van Asbroeck wrote:
> On Tue, Feb 26, 2019 at 10:45 AM Russell King - ARM Linux admin
> wrote:
> >
> >
> > I can't see how you'd extend a single I2S setup to support multi-
> > channel audio without eit
On Fri, Jan 25, 2019 at 09:40:38AM +, Russell King - ARM Linux admin wrote:
> Hi,
>
> This series adds support for programming the SPD and vendor infoframes.
>
> It also adds support for pixel repeated modes - we were not rejecting
> these modes, but we also didn't hav
On Tue, Feb 26, 2019 at 11:02:48AM +0100, Lucas Stach wrote:
> Hi Russell,
>
> Am Dienstag, den 26.02.2019, 09:24 + schrieb Russell King - ARM Linux
> admin:
> > I'm not sure when this happened, only that it happened sometime
> > overnight. It was left runnin
This series represents development work collected over the last six
months to improve the TDA998x driver, particularly for the audio
side. These patches can be found in my "drm-tda998x-devel" branch
at git://git.armlinux.org.uk/~rmk/linux-arm.git
- Introduce an audio_settings structure
On Wed, Jun 12, 2019 at 11:25:59AM -0400, Sven Van Asbroeck wrote:
> On Tue, Jun 11, 2019 at 7:02 AM Russell King
> wrote:
> >
> > Improve the selection of the audio clock divisor so that more modes
> > and sample rates work.
> >
> > Signed-off-by: Russell King
> > ---
>
> +static u8 tda998x_ge
On Wed, Jun 12, 2019 at 11:27:16AM -0400, Sven Van Asbroeck wrote:
> On Tue, Jun 11, 2019 at 7:02 AM Russell King
> wrote:
> >
> > The TDA998x derives the CTS value using the supplied I2S bit clock
> > (ACLK, in TDA998x parlence) rather than 128·fs. TDA998x uses two
> > constants named m and k i
On Wed, Jun 12, 2019 at 11:36:59AM -0400, Sven Van Asbroeck wrote:
> On Tue, Jun 11, 2019 at 7:02 AM Russell King
> wrote:
> >
> > Move the mux and clocking selection out of tda998x_configure_audio()
> > into the parent functions, so we can validate this when parameters
> > are set outside of the
On Wed, Jun 12, 2019 at 12:37:57PM -0400, Sven Van Asbroeck wrote:
> On Wed, Jun 12, 2019 at 12:28 PM Russell King - ARM Linux admin
> wrote:
> >
> > The platform data path has never supported the HDMI codec way of doing
> > things, so that really isn't a concern
On Wed, Jun 12, 2019 at 11:24:46AM -0400, Sven Van Asbroeck wrote:
> On Tue, Jun 11, 2019 at 7:01 AM Russell King
> wrote:
> >
> > Introduce a structure to hold the register values to be programmed while
> > programming the TDA998x audio settings. This is currently a stub
> > structure, which wi
On Wed, Jun 12, 2019 at 11:38:06AM -0400, Sven Van Asbroeck wrote:
> On Tue, Jun 11, 2019 at 7:04 AM Russell King
> wrote:
> >
> > Add bridge timing information so that bridge users can figure out the
> > timing parameters that are necessary for TDA998x.
> >
> > Signed-off-by: Russell King
> > -
On Wed, Jun 12, 2019 at 11:40:43AM -0400, Sven Van Asbroeck wrote:
> On Tue, Jun 11, 2019 at 7:01 AM Russell King - ARM Linux admin
> wrote:
> >
> > This series represents development work collected over the last six
> > months to improve the TDA998x driver, particularl
This series represents development work collected over the last six
months to improve the TDA998x driver, particularly for the audio
side. These patches can be found in my "drm-tda998x-devel" branch
at git://git.armlinux.org.uk/~rmk/linux-arm.git
- Introduce an audio_settings structure
On Thu, Jun 13, 2019 at 03:28:50PM +0200, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
Please don't merge this patch - I have a c
Hi,
This series updates Armada DRM:
- Fix interlace support.
- use __drm_atomic_helper_plane_reset in overlay reset.
- since the overlay and video planes use essentially the same format
registers, precompute their values while validating.
- fix a long-standing deficiency with overlay planes and
On Thu, Jun 13, 2019 at 06:01:14PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jun 13, 2019 at 03:36:00PM +0100, Russell King - ARM Linux admin
> wrote:
> > On Thu, Jun 13, 2019 at 03:28:50PM +0200, Greg Kroah-Hartman wrote:
> > > When calling debugfs functions, there is no n
On Thu, Jun 13, 2019 at 02:48:47PM -0400, Sven Van Asbroeck wrote:
> Nit: checkpatch.pl appears unhappy with this patch:
>
> WARNING: line over 80 characters
> #222: FILE: drivers/gpu/drm/i2c/tda998x_drv.c:1011:
> + audio.params.config = priv->audio_port[i].config;
>
> WARNING: line over 80 chara
On Thu, Jun 13, 2019 at 03:51:06PM -0400, Sven Van Asbroeck wrote:
> On Thu, Jun 13, 2019 at 10:29 AM Russell King - ARM Linux admin
> wrote:
> >
> > This series represents development work collected over the last six
> > months to improve the TDA998x driver, particularl
On Mon, May 27, 2019 at 03:15:51PM -0400, Sven Van Asbroeck wrote:
> The tda988x i2c chip registers are accessed through a
> paged register scheme. The kernel regmap abstraction
> supports paged accesses. Replace this driver's
> dedicated i2c access functions with a standard i2c
> regmap.
>
> Pros
On Mon, May 27, 2019 at 03:15:52PM -0400, Sven Van Asbroeck wrote:
> -static void
> -reg_set(struct tda998x_priv *priv, u16 reg, u8 val)
> +static int
> +reg_set(struct regmap *regmap, u16 reg, u8 val)
I don't see the point of making this return an 'int' - you don't modify
any of the callsites to
On Fri, Jun 21, 2019 at 05:13:33PM -0400, Sven Van Asbroeck wrote:
> On Fri, Jun 21, 2019 at 11:15 AM Russell King - ARM Linux admin
> wrote:
> >
> > Another con is the need to keep the functions that detail the register
> > properties up to date, which if they're w
While updating my various systems for the TCP SACK issue, I notice
that while most platforms are happy, the Cubox-i4 is not. During
boot, we get:
[0.00] cma: Reserved 256 MiB at 0x3000
...
[0.00] Kernel command line: console=ttymxc0,115200n8 console=tty1
video=mxcfb0:dev=hdmi
On Tue, Jun 25, 2019 at 11:46:34AM +0200, Andrzej Pietrasiewicz wrote:
> It is difficult for a user to know which of the i2c adapters is for which
> drm connector. This series addresses this problem.
>
> The idea is to have a symbolic link in connector's sysfs directory, e.g.:
>
> ls -l /sys/clas
On Tue, Jun 25, 2019 at 12:14:27PM +0200, Andrzej Pietrasiewicz wrote:
> Hi Russell,
>
> W dniu 25.06.2019 o 12:03, Russell King - ARM Linux admin pisze:
> > On Tue, Jun 25, 2019 at 11:46:34AM +0200, Andrzej Pietrasiewicz wrote:
> > > It is difficult for a user to know w
1401 - 1500 of 1619 matches
Mail list logo