On Tue, Dec 17, 2013 at 01:04:20PM +0800, Shawn Guo wrote:
> On Mon, Dec 16, 2013 at 12:38:23PM +0000, Russell King - ARM Linux wrote:
> > Russell King (8):
> > imx-drm: imx-drm-core: fix error cleanup path for imx_drm_add_crtc()
> > imx-drm: imx-drm-core:
On Tue, Dec 17, 2013 at 12:28:37PM +0800, Shawn Guo wrote:
> On Mon, Dec 16, 2013 at 11:34:05AM +, Russell King wrote:
> > Trying to build a modular imx-drm results in a number of missing symbol
> > exports, caused by the recent changes to this driver. Add the necessary
> > exports, and the mi
On Mon, Dec 16, 2013 at 11:33:01AM +, Russell King - ARM Linux wrote:
> The following patch series fixes some bugs and races in the imx-drm
> code, which should probably be applied to an -rc kernel.
>
> drivers/staging/imx-drm/imx-drm-core.c | 21 -
>
The following patch series fixes some bugs and races in the imx-drm
code, which should probably be applied to an -rc kernel.
drivers/staging/imx-drm/imx-drm-core.c | 21 -
drivers/staging/imx-drm/ipu-v3/ipu-common.c | 32 +-
drivers/staging/imx-drm
On Tue, Dec 03, 2013 at 07:44:52PM +0800, Shawn Guo wrote:
> On Mon, Dec 02, 2013 at 04:39:26PM +0100, Marek Vasut wrote:
> > Add DRM flags for the LCD display clock polarity so the pixelclk-active DT
> > property can be properly handled by drivers using the DRM API.
> >
> > Signed-off-by: Marek V
On Mon, Dec 02, 2013 at 04:39:26PM +0100, Marek Vasut wrote:
> Add DRM flags for the LCD display clock polarity so the pixelclk-active DT
> property can be properly handled by drivers using the DRM API.
I still say that not even this should be part of the DRM mode API to
userspace. The hint that
On Wed, Nov 13, 2013 at 11:43:44AM -0700, Troy Kisky wrote:
> On 11/13/2013 2:23 AM, Denis Carikli wrote:
>> + /* rgb666 */
>> +ipu_dc_map_clear(priv, IPU_DC_MAP_RGB666);
>> +ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 2, 17, 0xfc); /* red */
>> +ipu_dc_map_config(priv, IPU_DC_MAP_RGB
On Wed, Nov 13, 2013 at 08:53:18AM +0100, Eric Bénard wrote:
> Hi Russell,
>
> Le Tue, 12 Nov 2013 17:04:55 +,
> Russell King - ARM Linux a écrit :
> > On Tue, Nov 12, 2013 at 05:49:18PM +0100, Denis Carikli wrote:
> > > diff --git a/drivers/gpu/drm/drm_modes.c b/
On Tue, Nov 12, 2013 at 05:49:18PM +0100, Denis Carikli wrote:
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index fc2adb6..586c12f 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -537,6 +537,15 @@ int drm_display_mode_from_videomode(
On Thu, Oct 31, 2013 at 06:45:41PM -0200, Fabio Estevam wrote:
> Hi Troy,
>
> On Thu, Oct 31, 2013 at 6:38 PM, Troy Kisky
> wrote:
>
> >> I get a magenta line down the left side of the screen unless I replace the
> >> 5 with a 6.
> >> ie.
> >>
> >> +for (count = 0; count < 6; count++)
> >> +
On Thu, Oct 31, 2013 at 09:46:40AM -0200, Mauro Carvalho Chehab wrote:
> Hi Russell,
>
> Em Mon, 30 Sep 2013 13:57:47 +0200
> Hans Verkuil escreveu:
>
> > On 09/19/2013 11:44 PM, Russell King wrote:
> > > Replace the following sequence:
> > >
> > > dma_set_mask(dev, mask);
> > > dma_set_coh
On Mon, Oct 28, 2013 at 06:26:49PM -0200, Fabio Estevam wrote:
> + /*Wait for PHY PLL lock */
> + msec = 4;
> + val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
> + while (!val) {
> + udelay(1000);
> + if (msec-- == 0) {
> +
On Tue, Oct 29, 2013 at 08:01:46PM -0200, Fabio Estevam wrote:
> Hi Greg,
>
> On Mon, Oct 28, 2013 at 7:03 PM, Greg KH wrote:
> > And why is new support being added to this driver instead of working to
> > get it out of staging?
>
> Philipp Zabel mentioned that he will submit the imx-drm driver
On Tue, Oct 29, 2013 at 07:42:22PM -0200, Fabio Estevam wrote:
> From: Fabio Estevam
>
> sig_cfg.clk_pol controls the 'di0_polarity_disp_clk' bit of register
> IPUx_DI0_GENERAL through the following code in imx-drm/ipu-v3/ipu-di.c:
>
> if (!sig->clk_pol)
> di_gen |= DI_GEN_PO
On Tue, Oct 29, 2013 at 01:45:50PM -0200, Fabio Estevam wrote:
> On Tue, Oct 29, 2013 at 1:00 PM, Fabio Estevam wrote:
>
> > Today I was able to get access to a wandboard solo and the HDMI image
> > does look different compared to a wandboard quad board:
> >
> > - The Linux logo penguins are stea
On Mon, Oct 28, 2013 at 06:26:49PM -0200, Fabio Estevam wrote:
> From: Fabio Estevam
>
> This is based on the initial work done by Sascha Hauer and Tony Prisk.
It looks like you've also taken some of the suggestions I've made too -
like the voltage drive and symbol transmit control settings.
It
On Sun, Oct 20, 2013 at 05:31:56PM +0100, Russell King - ARM Linux wrote:
> On Sun, Oct 20, 2013 at 02:00:57PM +0100, Russell King - ARM Linux wrote:
> > As for imx-drm, there was a warning which preceded that oops. Here's the
> > full log, below the "-" m
On Sun, Oct 20, 2013 at 02:00:57PM +0100, Russell King - ARM Linux wrote:
> As for imx-drm, there was a warning which preceded that oops. Here's the
> full log, below the "-" marker - this is from unbinding the imx-drm
> module, and then trying to reboot.
>
On Sun, Oct 20, 2013 at 01:04:34AM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 16, 2013 at 11:31:07AM -0700, Greg Kroah-Hartman wrote:
> > On Wed, Oct 16, 2013 at 07:07:35PM +0100, Russell King - ARM Linux wrote:
> > > Sorry, but I don't think imx-drm is driving
Another problem.
After performing several modesets, the IPU seems to lock up and produce
no syncs or output data.
I've seen this many times over the last week while testing out various
aspects of imx-drm, and had put it down to problems with the clocking
arrangement getting its settings wrong. N
On Wed, Oct 16, 2013 at 11:31:07AM -0700, Greg Kroah-Hartman wrote:
> On Wed, Oct 16, 2013 at 07:07:35PM +0100, Russell King - ARM Linux wrote:
> > Sorry, but I don't think imx-drm is driving the hardware correctly, and
> > I know that Greg wants it moved out of drivers/sta
Okay, next problem...
As I described via the Cubox-i community last night on google+...
I'm now at the point where certain resolutions and refreshes work fine
(eg, 720p @ 50 or 60Hz, 1366x768, 1024x768).
Others either don't display (1080p, 800x600, 848x480, 640x480), or have
speckles, a line of
On Wed, Oct 16, 2013 at 02:03:17PM -0700, Troy Kisky wrote:
> Freescale's kernel(imx_3.0.35_4.1.0) has this code
>
> video/mxc_hdmi.c-/* Workaround to clear the overflow condition */
> video/mxc_hdmi.c-static void mxc_hdmi_clear_overflow(void)
> video/mxc_hdmi.c-{
> video/mxc_hdmi.c- int coun
On Wed, Oct 16, 2013 at 12:37:42PM -0700, Troy Kisky wrote:
> On 10/16/2013 10:03 AM, Russell King - ARM Linux wrote:
>> On Tue, Oct 15, 2013 at 10:17:07AM -0300, Fabio Estevam wrote:
>>> On Tue, Oct 15, 2013 at 10:10 AM, Russell King - ARM Linux
>>> wrote:
>>&g
On Wed, Oct 16, 2013 at 11:31:07AM -0700, Greg Kroah-Hartman wrote:
> On Wed, Oct 16, 2013 at 07:07:35PM +0100, Russell King - ARM Linux wrote:
> > Sorry, but I don't think imx-drm is driving the hardware correctly, and
> > I know that Greg wants it moved out of drivers/sta
On Wed, Oct 16, 2013 at 06:03:42PM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 15, 2013 at 10:17:07AM -0300, Fabio Estevam wrote:
> > On Tue, Oct 15, 2013 at 10:10 AM, Russell King - ARM Linux
> > wrote:
> > > Another point on patch 1. Sorry, I don't
On Tue, Oct 15, 2013 at 10:17:07AM -0300, Fabio Estevam wrote:
> On Tue, Oct 15, 2013 at 10:10 AM, Russell King - ARM Linux
> wrote:
> > Another point on patch 1. Sorry, I don't have patch 1 to reply to, it
> > seems it was deleted from linux-arm-ke
Another point on patch 1. Sorry, I don't have patch 1 to reply to, it
seems it was deleted from linux-arm-kernel's moderation queue.
drm_mode_connector_attach_encoder() is called too early, before the
base.id field in the encoder has been initialised. This causes the
connectors encoder array to
On Tue, Oct 15, 2013 at 10:18:30AM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 15, 2013 at 09:46:18AM +0200, Sascha Hauer wrote:
> > This sounds like the wrong clock polarity. Could you try inverting
> > sig_cfg.clk_pol in imx-drm/ipuv3-crtc.c?
>
> I tweaked it a d
On Mon, Oct 14, 2013 at 11:47:17PM -0300, Fabio Estevam wrote:
> On Mon, Oct 14, 2013 at 2:38 PM, Russell King - ARM Linux
> wrote:
>
> > Shouldn't the above be in patch 1 (or 1.5) rather than patch 2? Patch 2
> > advertises itself as adding support for the wandboa
On Tue, Oct 15, 2013 at 09:46:18AM +0200, Sascha Hauer wrote:
> On Mon, Oct 14, 2013 at 11:50:29PM +0100, Russell King - ARM Linux wrote:
> > Answers to these two questions may help stop me wasting a lot of time
> > chasing what is a really weird bug.
> >
> > So, I h
On Mon, Oct 14, 2013 at 06:40:30PM +0100, Russell King - ARM Linux wrote:
> Another thing that my build testing (and use on cubox-i) picked up:
>
> On Thu, Oct 03, 2013 at 03:51:26PM -0300, Fabio Estevam wrote:
> > diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/
On Thu, Oct 03, 2013 at 03:51:26PM -0300, Fabio Estevam wrote:
> diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
> index 9e8ae11..65e54b4 100644
> --- a/arch/arm/boot/dts/imx6dl.dtsi
> +++ b/arch/arm/boot/dts/imx6dl.dtsi
> @@ -88,3 +88,7 @@
> crtcs = <&ipu1
Another thing that my build testing (and use on cubox-i) picked up:
On Thu, Oct 03, 2013 at 03:51:26PM -0300, Fabio Estevam wrote:
> diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
> index 9e8ae11..65e54b4 100644
> --- a/arch/arm/boot/dts/imx6dl.dtsi
> +++ b/arch/arm/boo
On Wed, Oct 09, 2013 at 08:07:12PM -0300, Fabio Estevam wrote:
> In order to avoid this lockdep warning, remove the locking from
> imx_drm_encoder_get_mux_id() and imx_drm_crtc_panel_format_pins().
>
> Tested on a mx6sabrelite and mx53qsb.
>
> Reported-by: Russell King
> Signed-off-by: Fabio Es
A suggestion to IMX developers: please run your test kernels with
PROVE_LOCKING enabled (and preferably other debugging options too.)
Thanks.
==
[ INFO: possible circular locking dependency detected ]
3.12.0-rc3+ #43 Not tainted
-
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
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 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 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 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
On Fri, Sep 20, 2013 at 04:42:08PM +0100, Ben Hutchings wrote:
> On Thu, 2013-09-19 at 22:43 +0100, Russell King wrote:
> > + if (dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)) ||
> > + dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32))) {
>
> Surely we want && here.
Good ca
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: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 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
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 Thu, Sep 05, 2013 at 05:15:02PM -0300, Fabio Estevam wrote:
> Looks good, just one minor suggestion:
>
> On Thu, Sep 5, 2013 at 3:16 PM, Dan Carpenter
> wrote:
> > +static void lradc_reg_set(struct mxs_lradc *lradc, u32 val, size_t chan)
> > +{
> > + writel(val, lradc->base + chan + STM
301 - 347 of 347 matches
Mail list logo
