Re: [PATCH v4 1/4] Input: ads7846 - Convert to use software nodes

[Aaro Koskinen]

Hi,

On Mon, May 08, 2023 at 11:20:06PM +0200, Linus Walleij wrote:
> The CBUS also has the ADS7846 touchscreen attached.

Not sure what this comment means. CBUS is for Retu/Tahvo, and touchscreen
is SPI.

When tested w/gpio-descriptors-omap branch, the touchscreen probe fails:

[2.378540] SPI driver ads7846 has no spi_device_id for ti,tsc2046
[2.391906] SPI driver ads7846 has no spi_device_id for ti,ads7843
[2.405029] SPI driver ads7846 has no spi_device_id for ti,ads7845
[2.418151] SPI driver ads7846 has no spi_device_id for ti,ads7873
[2.432556] ads7846 spi2.0: Unknown device model
[2.443817] ads7846: probe of spi2.0 failed with error -22

I don't know if that's caused by any the patches in the branch or some
other regression. With v6.2 it probes OK.

A.

Re: [PATCH v4 2/4] ARM/mmc: Convert old mmci-omap to GPIO descriptors

[Aaro Koskinen]

Hi,

This one has some issue as mmci-omap is unable to find the GPIOs on 770.

On Mon, May 08, 2023 at 11:20:07PM +0200, Linus Walleij wrote:
> +static struct gpiod_lookup_table nokia770_mmc_gpio_table = {
> + .dev_id = "mmci-omap",

Changing this to "mmci-omap.1" helped, not sure if that is a correct way.
Most likely N800 and N810 are broken as well.

A.

Re: [PATCH v4 1/4] Input: ads7846 - Convert to use software nodes

[Aaro Koskinen]

Hi,

This does not compile as nokia770_ads7846_props is declared twice,
and nokia770_cbus_props and nokia770_mpuio_gpiochip_swnode are missing.

On Mon, May 08, 2023 at 11:20:06PM +0200, Linus Walleij wrote:
> +static const struct software_node_ref_args nokia770_cbus_gpio_refs[] = {
> + SOFTWARE_NODE_REFERENCE(_mpuio_gpiochip_swnode, 9, 0),
> + SOFTWARE_NODE_REFERENCE(_mpuio_gpiochip_swnode, 10, 0),
> + SOFTWARE_NODE_REFERENCE(_mpuio_gpiochip_swnode, 11, 0),
> +};

These should be nokia770_mpuio_gpiochip_node.

> +static const struct property_entry nokia770_ads7846_props[] = {
> + PROPERTY_ENTRY_REF_ARRAY("gpios", nokia770_cbus_gpio_refs),
> + { }
>  };

This should be nokia770_cbus_props.

A.

Re: [PATCH 14/17] ARM: omap1: remove dead code

[Aaro Koskinen]

Hi,

On Wed, Oct 19, 2022 at 05:03:36PM +0200, Arnd Bergmann wrote:
>  drivers/usb/phy/phy-isp1301-omap.c | 91 +-

This driver and config option ISP1301_OMAP can be deleted altogether as
there are no users after H2/H3 boards are gone.

A.

Re: [PATCH 00/41] OMAP1 full multiplatform conversion

[Aaro Koskinen]

Hi,

On Wed, Apr 20, 2022 at 10:00:13PM +0200, Arnd Bergmann wrote:
> On Wed, Apr 20, 2022 at 7:08 PM Aaro Koskinen  wrote:
> > On Tue, Apr 19, 2022 at 03:36:42PM +0200, Arnd Bergmann wrote:
> > > From: Arnd Bergmann 
> > >
> > > This is the full series for converting OMAP1 to multiplatform, rebased
> > > from my 2019 attempt to do the same thing. The soc tree contains simpler
> > > patches to do the same for iop32x, ixp4xx, ep93xx and s3c24xx, which
> > > means we are getting closer to completing this for all ARMv5 platforms
> > > (I have patches for PXA, which is the last one remaining).
> > >
> > > Janusz already tested the branch separately and did the missing work
> > > for the common-clk conversion after my previous approach was broken.
> >
> > I tested the full series on the following OMAP1 boards: ams-delta,
> > nokia770, osk, palmte and sx1 (QEMU only).
> >
> > Apart from the earlyprintk breakage, everything seemed to work OK.
> 
> Nice, thanks a lot for testing!

With the updated patch 26 also earlyprintk now works, so if you still
update the patches, feel free to add for the whole series:

Tested-by: Aaro Koskinen 

Thanks,

A.

Re: [PATCH 26/41] ARM: omap1: relocate static I/O mapping

[Aaro Koskinen]

Hi,

On Tue, Apr 19, 2022 at 03:37:08PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> The address range 0xfee0-0xfeff is used for PCI and
> PCMCIA I/O port mappings, but OMAP1 has its static mappings
> there as well.
> 
> Move the OMAP1 addresses a little higher to avoid crashing
> at boot.

This has the same problem I reported in 2019, with earlyprintk the
system no longer boots:

https://marc.info/?t=15653001425=1=2

Tested on OSK and SX1/qemu.

A.

> Signed-off-by: Arnd Bergmann 
> ---
>  arch/arm/Kconfig.debug  | 6 +++---
>  arch/arm/mach-omap1/include/mach/hardware.h | 2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 0c9497d549e3..f57b449000f7 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -1837,9 +1837,9 @@ config DEBUG_UART_VIRT
>   default 0xfec0 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
>   default 0xfec3 if ARCH_IXP4XX && CPU_BIG_ENDIAN
>   default 0xfef36000 if DEBUG_HIGHBANK_UART
> - default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
> - default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
> - default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
> + default 0xff00 if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
> + default 0xff000800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
> + default 0xff009800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
>   default 0xffd01000 if DEBUG_HIP01_UART
>   default DEBUG_UART_PHYS if !MMU
>   depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
> diff --git a/arch/arm/mach-omap1/include/mach/hardware.h 
> b/arch/arm/mach-omap1/include/mach/hardware.h
> index 05c5cd3e95f4..e3522e601ccd 100644
> --- a/arch/arm/mach-omap1/include/mach/hardware.h
> +++ b/arch/arm/mach-omap1/include/mach/hardware.h
> @@ -63,7 +63,7 @@ static inline u32 omap_cs3_phys(void)
>  
>  #endif   /* ifndef __ASSEMBLER__ */
>  
> -#define OMAP1_IO_OFFSET  0x0100  /* Virtual IO = 
> 0xfefb */
> +#define OMAP1_IO_OFFSET  0x00fb  /* Virtual IO = 
> 0xff00 */
>  #define OMAP1_IO_ADDRESS(pa) IOMEM((pa) - OMAP1_IO_OFFSET)
>  
>  #include 
> -- 
> 2.29.2
> 

Re: [PATCH 00/41] OMAP1 full multiplatform conversion

[Aaro Koskinen]

Hi,

On Tue, Apr 19, 2022 at 03:36:42PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> This is the full series for converting OMAP1 to multiplatform, rebased
> from my 2019 attempt to do the same thing. The soc tree contains simpler
> patches to do the same for iop32x, ixp4xx, ep93xx and s3c24xx, which
> means we are getting closer to completing this for all ARMv5 platforms
> (I have patches for PXA, which is the last one remaining).
> 
> Janusz already tested the branch separately and did the missing work
> for the common-clk conversion after my previous approach was broken.

I tested the full series on the following OMAP1 boards: ams-delta,
nokia770, osk, palmte and sx1 (QEMU only).

Apart from the earlyprintk breakage, everything seemed to work OK.

A minor note, zImage grows about 50 KB with a minimal kernel config. This
is not yet critical, there's still about 7% headroom on 770 to the 2 MB
bootloader limit on my setup. Also the decompression time is approaching
the hardcoded watchdog timeout...

A.

Re: [PATCH] OMAP: DSS2: OMAPFB: fix potential GPF

[Aaro Koskinen]

Hi,

On Sat, Jun 26, 2021 at 01:33:23AM +0300, Pavel Skripkin wrote:
> In case of allocation failures, all code paths was jumping
> to this code:
> 
> err:
>   kfree(fbi);
>   kfree(var);
>   kfree(fbops);
> 
>   return r;
> 
> Since all 3 pointers placed on stack and don't initialized, they
> will be filled with some random values, which leads to
> deferencing random pointers in kfree(). Fix it by rewriting
> error handling path.

They are initialized before the first goto:

[...]
fbi = NULL;
var = NULL;
fbops = NULL;

fbi = kzalloc(sizeof(*fbi), GFP_KERNEL);
if (fbi == NULL) {
r = -ENOMEM;
goto err;
}
[...]

A.

Re: [PATCH] drm/omap: sdi: fix bridge enable/disable

[Aaro Koskinen]

Hi,

On Fri, Nov 27, 2020 at 10:52:41AM +0200, Tomi Valkeinen wrote:
> When the SDI output was converted to DRM bridge, the atomic versions of
> enable and disable funcs were used. This was not intended, as that would
> require implementing other atomic funcs too. This leads to:
> 
> WARNING: CPU: 0 PID: 18 at drivers/gpu/drm/drm_bridge.c:708 
> drm_atomic_helper_commit_modeset_enables+0x134/0x268
> 
> and display not working.
> 
> Fix this by using the legacy enable/disable funcs.
> 
> Signed-off-by: Tomi Valkeinen 
> Reported-by: Aaro Koskinen 
> Fixes: 8bef8a6d5da81b909a190822b96805a47348146f ("drm/omap: sdi: Register a 
> drm_bridge")
> Cc: sta...@vger.kernel.org # v5.7+
> Tested-by: Ivaylo Dimitrov 

Tested-by: Aaro Koskinen 

Thanks,

A.

> ---
>  drivers/gpu/drm/omapdrm/dss/sdi.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/sdi.c 
> b/drivers/gpu/drm/omapdrm/dss/sdi.c
> index 033fd30074b0..282e4c837cd9 100644
> --- a/drivers/gpu/drm/omapdrm/dss/sdi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/sdi.c
> @@ -195,8 +195,7 @@ static void sdi_bridge_mode_set(struct drm_bridge *bridge,
>   sdi->pixelclock = adjusted_mode->clock * 1000;
>  }
>  
> -static void sdi_bridge_enable(struct drm_bridge *bridge,
> -   struct drm_bridge_state *bridge_state)
> +static void sdi_bridge_enable(struct drm_bridge *bridge)
>  {
>   struct sdi_device *sdi = drm_bridge_to_sdi(bridge);
>   struct dispc_clock_info dispc_cinfo;
> @@ -259,8 +258,7 @@ static void sdi_bridge_enable(struct drm_bridge *bridge,
>   regulator_disable(sdi->vdds_sdi_reg);
>  }
>  
> -static void sdi_bridge_disable(struct drm_bridge *bridge,
> -struct drm_bridge_state *bridge_state)
> +static void sdi_bridge_disable(struct drm_bridge *bridge)
>  {
>   struct sdi_device *sdi = drm_bridge_to_sdi(bridge);
>  
> @@ -278,8 +276,8 @@ static const struct drm_bridge_funcs sdi_bridge_funcs = {
>   .mode_valid = sdi_bridge_mode_valid,
>   .mode_fixup = sdi_bridge_mode_fixup,
>   .mode_set = sdi_bridge_mode_set,
> - .atomic_enable = sdi_bridge_enable,
> - .atomic_disable = sdi_bridge_disable,
> + .enable = sdi_bridge_enable,
> + .disable = sdi_bridge_disable,
>  };
>  
>  static void sdi_bridge_init(struct sdi_device *sdi)
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/panel: sony-acx565akm: Fix race condition in probe

[Aaro Koskinen]

Hi,

On Fri, Nov 27, 2020 at 09:04:29PM +0100, Sebastian Reichel wrote:
> The probe routine acquires the reset GPIO using GPIOD_OUT_LOW. Directly
> afterwards it calls acx565akm_detect(), which sets the GPIO value to
> HIGH. If the bootloader initialized the GPIO to HIGH before the probe
> routine was called, there is only a very short time period of a few
> instructions where the reset signal is LOW. Exact time depends on
> compiler optimizations, kernel configuration and alignment of the stars,
> but I expect it to be always way less than 10us. There are no public
> datasheets for the panel, but acx565akm_power_on() has a comment with
> timings and reset period should be at least 10us. So this potentially
> brings the panel into a half-reset state.
> 
> The result is, that panel may not work after boot and can get into a
> working state by re-enabling it (e.g. by blanking + unblanking), since
> that does a clean reset cycle. This bug has recently been hit by Ivaylo
> Dimitrov, but there are some older reports which are probably the same
> bug. At least Tony Lindgren, Peter Ujfalusi and Jarkko Nikula have
> experienced it in 2017 describing the blank/unblank procedure as
> possible workaround.
> 
> Note, that the bug really goes back in time. It has originally been
> introduced in the predecessor of the omapfb driver in 3c45d05be382
> ("OMAPDSS: acx565akm panel: handle gpios in panel driver") in 2012.
> That driver eventually got replaced by a newer one, which had the bug
> from the beginning in 84192742d9c2 ("OMAPDSS: Add Sony ACX565AKM panel
> driver") and still exists in fbdev world. That driver has later been
> copied to omapdrm and then was used as a basis for this driver. Last
> but not least the omapdrm specific driver has been removed in
> 45f16c82db7e ("drm/omap: displays: Remove unused panel drivers").
> 
> Reported-by: Jarkko Nikula 
> Reported-by: Peter Ujfalusi 
> Reported-by: Tony Lindgren 
> Reported-by: Aaro Koskinen 
> Reported-by: Ivaylo Dimitrov 
> Cc: Merlijn Wajer 
> Cc: Laurent Pinchart 
> Cc: Tomi Valkeinen 
> Fixes: 1c8fc3f0c5d2 ("drm/panel: Add driver for the Sony ACX565AKM panel")
> Signed-off-by: Sebastian Reichel 

Tested-by: Aaro Koskinen 

Thanks,

A.

> ---
>  drivers/gpu/drm/panel/panel-sony-acx565akm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-sony-acx565akm.c 
> b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> index e95fdfb16b6c..ba0b3ead150f 100644
> --- a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> +++ b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> @@ -629,7 +629,7 @@ static int acx565akm_probe(struct spi_device *spi)
>   lcd->spi = spi;
>   mutex_init(>mutex);
>  
> - lcd->reset_gpio = devm_gpiod_get(>dev, "reset", GPIOD_OUT_LOW);
> + lcd->reset_gpio = devm_gpiod_get(>dev, "reset", GPIOD_OUT_HIGH);
>   if (IS_ERR(lcd->reset_gpio)) {
>   dev_err(>dev, "failed to get reset GPIO\n");
>   return PTR_ERR(lcd->reset_gpio);
> -- 
> 2.29.2
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/omap: Fix port lookup for SDI output

[Aaro Koskinen]

Hi,

On Wed, Aug 21, 2019 at 09:32:26PM +0300, Laurent Pinchart wrote:
> When refactoring port lookup for DSS outputs, commit d17eb4537a7e
> ("drm/omap: Factor out common init/cleanup code for output devices")
> incorrectly hardcoded usage of DT port 0. This breaks operation for SDI
> (which uses the DT port 1) and DPI outputs other than DPI0 (which are
> not used in mainline DT sources).
> 
> Fix this by using the port number from the output omap_dss_device
> of_ports field.
> 
> Fixes: d17eb4537a7e ("drm/omap: Factor out common init/cleanup code for 
> output devices")
> Signed-off-by: Laurent Pinchart 

Tested-by: Aaro Koskinen 

Thanks, this fixes the display issue on N900.

A.

> ---
>  drivers/gpu/drm/omapdrm/dss/output.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/output.c 
> b/drivers/gpu/drm/omapdrm/dss/output.c
> index de0f882f0f7b..14b41de44ebc 100644
> --- a/drivers/gpu/drm/omapdrm/dss/output.c
> +++ b/drivers/gpu/drm/omapdrm/dss/output.c
> @@ -4,6 +4,7 @@
>   * Author: Archit Taneja 
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -20,7 +21,8 @@ int omapdss_device_init_output(struct omap_dss_device *out)
>  {
>   struct device_node *remote_node;
>  
> - remote_node = of_graph_get_remote_node(out->dev->of_node, 0, 0);
> + remote_node = of_graph_get_remote_node(out->dev->of_node,
> +ffs(out->of_ports) - 1, 0);
>   if (!remote_node) {
>   dev_dbg(out->dev, "failed to find video sink\n");
>   return 0;
> -- 
> Regards,
> 
> Laurent Pinchart
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] video: fbdev: omap2: remove rfbi

[Aaro Koskinen]

Hi,

On Mon, Apr 30, 2018 at 10:06:11AM +0300, Tomi Valkeinen wrote:
> On 27/04/18 21:12, Aaro Koskinen wrote:
> >> You should be targeting omapdrm driver instead, fbdev subsystem is closed
> >> for the new hardware support.
> > 
> > AFAIK, based on N950 display support discussion, it's impossible to get
> > anything new into omapdrm for a long time. And based on Tomi's comments,
> > restoring RFBI support with omapfb should be a minor thing.
> 
> I was perhaps a bit vague, but I didn't say it should be a minor thing.
> I meant that there should be no architectural obstacles in omapfb, and I
> think all the generic plumbing to enable N800 display is there in omapfb.
> 
> That said, it still needs a real amount of work with the rfbi driver,
> the encoder driver and the panel driver on N800 (the encoder and the
> panel driver are not in mainline anymore).

Let's see first if I get anything working. After that we can evaluate
the impact properly once we see the actual patches needed.

A.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] video: fbdev: omap2: remove rfbi

[Aaro Koskinen]

Hi,

On Mon, Apr 30, 2018 at 05:34:59PM +0200, Bartlomiej Zolnierkiewicz wrote:
> BROKEN is not an user selectable config option so without modifying
> drivers/video/fbdev/omap2/omapfb/dss/Kconfig the RFBI driver is not
> even included in the kernel build..

Yes, I know. It's still incorrect to state that the code "doesn't even
compile".

A.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] video: fbdev: omap2: remove rfbi

[Aaro Koskinen]

Hi,

On Fri, Apr 27, 2018 at 05:09:14PM +0200, Bartlomiej Zolnierkiewicz wrote:
> omapfb equivalent of drm's commit aa61321d4c08 ("drm/omap: remove rfbi"):
> 
> The RFBI driver has not worked nor compiled for many years. There are
> very few boards out there that use RFBI, and no one has stepped up to
> fix it.
>
> So let's remove the RFBI code that doesn't even compile.

NACK. I'm just about to start fixing this and hoping to get display
working on N8x0 boards.

See the other thread: https://marc.info/?l=linux-omap=152469100217934=2

A.

> Cc: Tomi Valkeinen 
> Cc: Laurent Pinchart 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
>  drivers/video/fbdev/omap2/omapfb/dss/Kconfig  |   13 
>  drivers/video/fbdev/omap2/omapfb/dss/Makefile |1 
>  drivers/video/fbdev/omap2/omapfb/dss/core.c   |6 
>  drivers/video/fbdev/omap2/omapfb/dss/dss.h|4 
>  drivers/video/fbdev/omap2/omapfb/dss/rfbi.c   | 1078 
> --
>  include/video/omapfb_dss.h|   32 
>  6 files changed, 1134 deletions(-)
>  delete mode 100644 drivers/video/fbdev/omap2/omapfb/dss/rfbi.c
> 
> Index: b/drivers/video/fbdev/omap2/omapfb/dss/Kconfig
> ===
> --- a/drivers/video/fbdev/omap2/omapfb/dss/Kconfig2018-04-27 
> 16:24:48.171632007 +0200
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/Kconfig2018-04-27 
> 16:25:31.067633088 +0200
> @@ -42,19 +42,6 @@ config FB_OMAP2_DSS_DPI
>   help
> DPI Interface. This is the Parallel Display Interface.
>  
> -config FB_OMAP2_DSS_RFBI
> - bool "RFBI support"
> - depends on BROKEN
> -default n
> - help
> -   MIPI DBI support (RFBI, Remote Framebuffer Interface, in Texas
> -   Instrument's terminology).
> -
> -   DBI is a bus between the host processor and a peripheral,
> -   such as a display or a framebuffer chip.
> -
> -   See http://www.mipi.org/ for DBI specifications.
> -
>  config FB_OMAP2_DSS_VENC
>   bool "VENC support"
>  default y
> Index: b/drivers/video/fbdev/omap2/omapfb/dss/Makefile
> ===
> --- a/drivers/video/fbdev/omap2/omapfb/dss/Makefile   2018-04-27 
> 16:24:48.171632007 +0200
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/Makefile   2018-04-27 
> 16:26:20.511634333 +0200
> @@ -8,7 +8,6 @@ omapdss-y := core.o dss.o dss_features.o
>  omapdss-y += manager.o manager-sysfs.o overlay.o overlay-sysfs.o apply.o \
>   dispc-compat.o display-sysfs.o
>  omapdss-$(CONFIG_FB_OMAP2_DSS_DPI) += dpi.o
> -omapdss-$(CONFIG_FB_OMAP2_DSS_RFBI) += rfbi.o
>  omapdss-$(CONFIG_FB_OMAP2_DSS_VENC) += venc.o
>  omapdss-$(CONFIG_FB_OMAP2_DSS_SDI) += sdi.o
>  omapdss-$(CONFIG_FB_OMAP2_DSS_DSI) += dsi.o
> Index: b/drivers/video/fbdev/omap2/omapfb/dss/core.c
> ===
> --- a/drivers/video/fbdev/omap2/omapfb/dss/core.c 2018-04-27 
> 16:24:48.171632007 +0200
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/core.c 2018-04-27 
> 16:26:00.675633833 +0200
> @@ -251,9 +251,6 @@ static int (*dss_output_drv_reg_funcs[])
>  #ifdef CONFIG_FB_OMAP2_DSS_SDI
>   sdi_init_platform_driver,
>  #endif
> -#ifdef CONFIG_FB_OMAP2_DSS_RFBI
> - rfbi_init_platform_driver,
> -#endif
>  #ifdef CONFIG_FB_OMAP2_DSS_VENC
>   venc_init_platform_driver,
>  #endif
> @@ -275,9 +272,6 @@ static void (*dss_output_drv_unreg_funcs
>  #ifdef CONFIG_FB_OMAP2_DSS_VENC
>   venc_uninit_platform_driver,
>  #endif
> -#ifdef CONFIG_FB_OMAP2_DSS_RFBI
> - rfbi_uninit_platform_driver,
> -#endif
>  #ifdef CONFIG_FB_OMAP2_DSS_SDI
>   sdi_uninit_platform_driver,
>  #endif
> Index: b/drivers/video/fbdev/omap2/omapfb/dss/dss.h
> ===
> --- a/drivers/video/fbdev/omap2/omapfb/dss/dss.h  2018-04-27 
> 16:24:48.171632007 +0200
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.h  2018-04-27 
> 16:24:48.171632007 +0200
> @@ -472,10 +472,6 @@ void hdmi4_uninit_platform_driver(void);
>  int hdmi5_init_platform_driver(void) __init;
>  void hdmi5_uninit_platform_driver(void);
>  
> -/* RFBI */
> -int rfbi_init_platform_driver(void) __init;
> -void rfbi_uninit_platform_driver(void);
> -
>  
>  #ifdef CONFIG_FB_OMAP2_DSS_COLLECT_IRQ_STATS
>  static inline void dss_collect_irq_stats(u32 irqstatus, unsigned *irq_arr)
> Index: b/drivers/video/fbdev/omap2/omapfb/dss/rfbi.c
> ===
> --- a/drivers/video/fbdev/omap2/omapfb/dss/rfbi.c 2018-04-27 
> 16:24:42.223631857 +0200
> +++ /dev/null 1970-01-01 00:00:00.0 +
> @@ -1,1078 +0,0 @@
> -/*
> - * linux/drivers/video/omap2/dss/rfbi.c
> - *
> - * Copyright (C) 2009 Nokia Corporation
> - * Author: Tomi Valkeinen 
> - *
> - * Some code and ideas taken from 

Re: [PATCH] video: fbdev: omap2: remove rfbi

[Aaro Koskinen]

Hi,

On Fri, Apr 27, 2018 at 05:09:14PM +0200, Bartlomiej Zolnierkiewicz wrote:
> omapfb equivalent of drm's commit aa61321d4c08 ("drm/omap: remove rfbi"):
> 
> The RFBI driver has not worked nor compiled for many years. There are

What is the build failure you are seeing?

When removing the "BROKEN", it seems to compile fine, only some sparse
warnings:

  CHECK   /home/aaro/git/devel/linux/drivers/video/fbdev/omap2/omapfb/dss/rfbi.c
/home/aaro/git/devel/linux/drivers/video/fbdev/omap2/omapfb/dss/rfbi.c:519:21: 
warning: expression using sizeof(void)
/home/aaro/git/devel/linux/drivers/video/fbdev/omap2/omapfb/dss/rfbi.c:519:21: 
warning: expression using sizeof(void)
/home/aaro/git/devel/linux/drivers/video/fbdev/omap2/omapfb/dss/rfbi.c:520:25: 
warning: expression using sizeof(void)
/home/aaro/git/devel/linux/drivers/video/fbdev/omap2/omapfb/dss/rfbi.c:520:25: 
warning: expression using sizeof(void)
/home/aaro/git/devel/linux/drivers/video/fbdev/omap2/omapfb/dss/rfbi.c:1018:16: 
error: return expression in void function
  CC [M]  drivers/video/fbdev/omap2/omapfb/dss/rfbi.o
  CC [M]  drivers/video/fbdev/omap2/omapfb/dss/hdmi_common.o

A.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] video: fbdev: omap2: remove rfbi

[Aaro Koskinen]

Hi,

On Fri, Apr 27, 2018 at 07:58:28PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Friday, April 27, 2018 08:47:14 PM Aaro Koskinen wrote:
> > On Fri, Apr 27, 2018 at 05:09:14PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > omapfb equivalent of drm's commit aa61321d4c08 ("drm/omap: remove rfbi"):
> > > 
> > > The RFBI driver has not worked nor compiled for many years. There are
> > > very few boards out there that use RFBI, and no one has stepped up to
> > > fix it.
> > >
> > > So let's remove the RFBI code that doesn't even compile.
> > 
> > NACK. I'm just about to start fixing this and hoping to get display
> > working on N8x0 boards.
> > 
> > See the other thread: https://marc.info/?l=linux-omap=152469100217934=2
> 
> You should be targeting omapdrm driver instead, fbdev subsystem is closed
> for the new hardware support.

AFAIK, based on N950 display support discussion, it's impossible to get
anything new into omapdrm for a long time. And based on Tomi's comments,
restoring RFBI support with omapfb should be a minor thing.

A.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/omap: work-around for omap3 display enable

[Aaro Koskinen]

Hi,

On Wed, Aug 23, 2017 at 12:33:08PM +0300, Tomi Valkeinen wrote:
> On 13/06/17 12:02, Tomi Valkeinen wrote:
> > Seems that on omap3 enabling a crtc without any planes causes a sync
> > lost flood. This only happens on the first enable, and after that it
> > works. This looks like an HW issue.
> > 
> > It's unclear why this is happening or how to fix it, but as a quick
> > work-around, this patch enables i734 errata work-around for omap2 and
> > omap3 too. The errata work-around enables and disables the LCD output
> > with a plane once when waking up the DSS IP, and it seems to resolve the
> > omap3 problem too. It is unclear if omap2 has the same issue, but it
> > probably has and the WA should have no side effects so it should be safe
> > to enable on omap2 too.
> 
> I was again debugging and testing this problem, and I don't think this patch
> works very well. I'm getting endless sync losts again.
> 
> Here's another try, this time changing how the omapdrm commits the new setup.
> At least for me this seems to work better.
>
> From fc5cc9678e130196012c17b37e555d53d3d3476b Mon Sep 17 00:00:00 2001
> From: Tomi Valkeinen 
> Date: Wed, 23 Aug 2017 12:19:02 +0300
> Subject: [PATCHv2] drm/omap: work-around for omap3 display enable

Thanks! I was finally able to test this (with v4.13). Multiple boots
and now the display is always working fine.

A.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Aaro Koskinen]

Hi,

On Fri, Jun 30, 2017 at 11:47:55AM +0300, Tomi Valkeinen wrote:
> > So, I don't know... I guess I need to try to invent some horrible hacks
> > around the driver to somehow manage the omap3 problems. Perhaps
> > disabling/enabling the outputs when sync lost happens...
> 
> Well, I tried that (attached), but it didn't work either. For some
> reason the error worker seems to stop after the disable. Possibly the
> irq flood keeps it from running, so maybe it should catch all the errors
> (I see underflows too).
> 
> Sorry, but I can't use more time on this today, and I'm leaving for
> vacation today. I hope Laurent can help during my absence.
> 
> We could try reverting the patch you mention, but I think it doesn't
> cause the problem.

True, reverting the patch only allows me to use display without connector.
And apparently it just works by luck.

> Did you have CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled earlier when
> things worked?

No. I have never enabled it before, I didn't even know it was supported
by the mainline.

> If you didn't, and the dts did not contain display aliases, I think the
> omapdrm may have started without TV. So maybe the TV side is the culprit,
> somehow (I couldn't find anything when I looked at that side either).

Could be. 

Here is the summary from my testing:

0) v4.17-rc7 + connector disabled

==> nothing happens, omapdrm waits forever for connector driver

1) v4.17-rc7 + connector disabled +
   Revert "drm/omap: Use omapdss_stack_is_ready()"

==> LCD error flood, system unusable

2) v4.17-rc7 + connector disabled +
   Revert "drm/omap: Use omapdss_stack_is_ready()" +
   Apply "drm/omap: work-around for omap3 display enable"

==> display works!

3) v4.17-rc7 + connector enabled +
   Revert "drm/omap: Use omapdss_stack_is_ready()" +
   Apply "drm/omap: work-around for omap3 display enable"

==> LCD error flood, system unusable

4) v4.17-rc7 + connector enabled +
   Apply "drm/omap: work-around for omap3 display enable"

==> LCD error flood, system unusable

A.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Aaro Koskinen]

Hi,

On Fri, Jun 30, 2017 at 09:41:35AM +0300, Tomi Valkeinen wrote:
> On 29/06/17 21:50, Aaro Koskinen wrote:
> > On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote:
> >> On 15/06/17 01:11, Aaro Koskinen wrote:
> >>> When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
> >>> is no display.
> >>
> >> Are you sure it doesn't probe? It fails the omapdss_stack_is_ready()
> >> check?
> > 
> > It appears the reason was that I didn't have
> > CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled.
> > 
> > I think that's wrong. I don't own an analog TV, so why should I enable
> > such option to get device's built-in display working?
> 
> Indeed. Unfortunately I don't have a solution for that.
> 
> DRM doesn't support adding devices after probe. So at omapdrm probe time
> we have to decide which displays to use. In the dts file, n900 defines
> the lcd and analog tv. omapdrm sees those, and, of course, must wait
> until their respective drivers have probed. If you don't have the
> display driver enabled, it's never loaded and omapdrm never probes as it
> keeps waiting for those.

Could you at least print some kind of message early in the boot ("omapdrm
is waiting for drivers for display x and y")?

A.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Aaro Koskinen]

Hi,

On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote:
> On 15/06/17 01:11, Aaro Koskinen wrote:
> > When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
> > is no display.
> 
> Are you sure it doesn't probe? It fails the omapdss_stack_is_ready()
> check?

It appears the reason was that I didn't have
CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled.

I think that's wrong. I don't own an analog TV, so why should I enable
such option to get device's built-in display working?

> If that's the case then this is easier to debug.

Sure it's always easy... when users do all the testing and debugging.

Is it just me or do other OMAP users fail to see omapdrm changes being
posted to linux-omap for testing or review purposes?

And now I face another issue. When I boot v4.12-rc7 with
CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled and your "misc fixes"
patches on N900, I get the error flood again, and the device is unusable:

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.12.0-rc7-omap3-los_f343c+-3-g51d3478 
(aaro@amd-fx-6350) (gcc version 6.3.0 (GCC) ) #1 Thu Jun 29 21:40:29 EEST 2017
[0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing 
instruction cache
[0.00] OF: fdt: Machine model: Nokia N900
[0.00] Memory policy: Data cache writeback
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp)
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 64770
[0.00] Kernel command line: console=ttyO2,115200 console=tty
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Memory: 242780K/261120K available (6144K kernel code, 210K 
rwdata, 1656K rodata, 6144K init, 1142K bss, 18340K reserved, 0K cma-reserved, 
0K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xd000 - 0xff80   ( 760 MB)
[0.00] lowmem  : 0xc000 - 0xcff0   ( 255 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc070   (7136 kB)
[0.00]   .init : 0xc090 - 0xc0f0   (6144 kB)
[0.00]   .data : 0xc0f0 - 0xc0f34be0   ( 211 kB)
[0.00].bss : 0xc0f34be0 - 0xc1052560   (1143 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 
interrupts
[0.00] Clocking rate (Crystal/Core/MPU): 19.2/332/500 MHz
[0.00] OMAP clockevent source: timer1 at 32768 Hz
[0.00] clocksource: 32k_counter: mask: 0x max_cycles: 
0x, max_idle_ns: 58327039986419 ns
[0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 
6553584741ns
[0.00] OMAP clocksource: 32k_counter at 32768 Hz
[0.000488] Console: colour dummy device 80x30
[0.001281] console [tty0] enabled
[0.001342] Calibrating delay loop... 496.43 BogoMIPS (lpj=2482176)
[0.048370] pid_max: default: 32768 minimum: 301
[0.048553] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.048583] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.049468] CPU: Testing write buffer coherency: ok
[0.050354] Setting up static identity map for 0x8010 - 0x80100060
[0.053131] devtmpfs: initialized
[0.087066] VFP support v0.3: implementor 41 architecture 3 part 30 variant 
c rev 1
[0.087707] clocksource: jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 1911260446275 ns
[0.087799] futex hash table entries: 256 (order: -1, 3072 bytes)
[0.087982] pinctrl core: initialized pinctrl subsystem
[0.089599] NET: Registered protocol family 16
[0.091156] DMA: preallocated 256 KiB pool for atomic coherent allocations
[0.113800] omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp
[0.114562] omap_hwmod: mcbsp3_sidetone using broken dt data from mcbsp
[0.162780] Reprogramming SDRC clock to 33200 Hz
[0.177429] OMAP GPIO hardware version 2.5
[0.200073] irq: no irq domain found for 
/ocp@6800/l4@4800/scm@2000/pinmux@30 !
[0.215637] omap-gpmc 6e00.gpmc: could not find pctldev for node 
/ocp@6800/l4@4800/scm@2000/pinmux@30/pinmux_gpmc_pins, deferring probe
[0.219879] RX-51: Enabling ARM errata 430973 workaround
[0.221710] RX-51: Registering OMAP3 HWRN

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Aaro Koskinen]

Hi,

On Thu, Jun 29, 2017 at 09:50:13PM +0300, Aaro Koskinen wrote:
> On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote:
> > On 15/06/17 01:11, Aaro Koskinen wrote:
> > > When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
> > > is no display.
> > 
> > Are you sure it doesn't probe? It fails the omapdss_stack_is_ready()
> > check?
> 
> It appears the reason was that I didn't have
> CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled.
> 
> I think that's wrong. I don't own an analog TV, so why should I enable
> such option to get device's built-in display working?
> 
> > If that's the case then this is easier to debug.
> 
> Sure it's always easy... when users do all the testing and debugging.
> 
> Is it just me or do other OMAP users fail to see omapdrm changes being
> posted to linux-omap for testing or review purposes?
> 
> And now I face another issue. When I boot v4.12-rc7 with
> CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled and your "misc fixes"
> patches on N900, I get the error flood again, and the device is unusable:
> 
> [0.00] Booting Linux on physical CPU 0x0

For the record, here is my kernel config:

#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 4.12.0-rc7 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_ARM_HAS_SG_CHAIN=y
CONFIG_MIGHT_HAVE_PCI=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_BANDGAP=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_VECTORS_BASE=0x
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION="-omap3"
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_HANDLE_DOMAIN_IRQ=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_CLOCKEVENTS=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TINY_SRCU=y
# CONFIG_TASKS_RCU is not set
# CONFIG_RCU_STALL_COMMON is not set
CONFIG_RCU_NEED_SEGCBLIST=y
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=20
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
CONFIG_GENERIC_SCHED_CLOCK=y
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_RD_GZIP is not set
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
CONFIG_RD_XZ=y
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_BPF=y
CONFIG_EXPERT=y
CONFIG_UID16=y
CONFIG_MULTIUSER=y
# CONFIG_SGETMASK_SYSCALL is not set
CONFIG_SYSFS_SYSCALL=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_POSIX_TIMERS=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_ABSOLUTE_PERCPU is not set
CONFIG_KALLSYMS_BASE_RELATIVE=y
CONFIG_PRINTK=y
CONFIG_PRINTK_NMI=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
# CONFIG_BPF_SYSCALL is not set
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_ADVISE_SYSC

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Aaro Koskinen]

Hi,

On Thu, Jun 15, 2017 at 10:28:31AM +0300, Peter Ujfalusi wrote:
> On 2017-06-15 01:11, Aaro Koskinen wrote:
> > When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
> > is no display.
> > 
> > Bisected to:
> > 
> > a09d2bc1503508c17ef3a71c6b1905e3660f3029 is the first bad commit
> > commit a09d2bc1503508c17ef3a71c6b1905e3660f3029
> > Author: Peter Ujfalusi <peter.ujfal...@ti.com>
> > Date:   Tue May 3 22:08:01 2016 +0300
> > 
> > drm/omap: Use omapdss_stack_is_ready() to check that the display stack 
> > is up
> > 
> > Instead of 'guessing' based on aliases of the status of the DSS drivers,
> > use the new interface to check that all needed drivers are loaded.
> > In this way we can be sure that all needed drivers are loaded so it is
> > safe to continue the probing of omapdrm.
> > This method will allow the omapdrm to be probed 'headless', without
> > outputs.
> > 
> > Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
> > Signed-off-by: Tomi Valkeinen <tomi.valkei...@ti.com>
> > 
> > Reverting the commit seems to fix the issue.
> 
> When you revert this patch do you see a warning saying:
> "could not connect display: blah" ? if so what is 'blah'?

No.

A.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Aaro Koskinen]

Hi,

On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote:
> On 15/06/17 01:11, Aaro Koskinen wrote:
> > When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
> > is no display.
> 
> Are you sure it doesn't probe? It fails the omapdss_stack_is_ready()
> check? If that's the case then this is easier to debug.

Yes I think so, I added debug prints to omap_connect_dssdevs() and
pdev_probe(), and it's omapdss_stack_is_ready() that is failing.

> > Bisected to:
> > 
> > a09d2bc1503508c17ef3a71c6b1905e3660f3029 is the first bad commit
> > commit a09d2bc1503508c17ef3a71c6b1905e3660f3029
> > Author: Peter Ujfalusi <peter.ujfal...@ti.com>
> > Date:   Tue May 3 22:08:01 2016 +0300
> > 
> > drm/omap: Use omapdss_stack_is_ready() to check that the display stack 
> > is up
> > 
> > Instead of 'guessing' based on aliases of the status of the DSS drivers,
> > use the new interface to check that all needed drivers are loaded.
> > In this way we can be sure that all needed drivers are loaded so it is
> > safe to continue the probing of omapdrm.
> > This method will allow the omapdrm to be probed 'headless', without
> > outputs.
> > 
> > Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
> > Signed-off-by: Tomi Valkeinen <tomi.valkei...@ti.com>
> > 
> > Reverting the commit seems to fix the issue.
> 
> This is probably "fixed" by adding the display aliases into the n900 dts
> file. The aliases should not really be required, although they are
> recommended. Without the aliases the order of the displays is random,
> and n900 could end up using tv-out as the first display. But even then,
> the displays should still work.

I'm using up-to-date DTS from the kernel tree.

A.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Aaro Koskinen]

Hi,

When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
is no display.

Bisected to:

a09d2bc1503508c17ef3a71c6b1905e3660f3029 is the first bad commit
commit a09d2bc1503508c17ef3a71c6b1905e3660f3029
Author: Peter Ujfalusi 
Date:   Tue May 3 22:08:01 2016 +0300

drm/omap: Use omapdss_stack_is_ready() to check that the display stack is up

Instead of 'guessing' based on aliases of the status of the DSS drivers,
use the new interface to check that all needed drivers are loaded.
In this way we can be sure that all needed drivers are loaded so it is
safe to continue the probing of omapdrm.
This method will allow the omapdrm to be probed 'headless', without
outputs.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Tomi Valkeinen 

Reverting the commit seems to fix the issue.

A.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/omap: work-around for omap3 display enable

[Aaro Koskinen]

Hi,

On Tue, Jun 13, 2017 at 12:02:08PM +0300, Tomi Valkeinen wrote:
> Seems that on omap3 enabling a crtc without any planes causes a sync
> lost flood. This only happens on the first enable, and after that it
> works. This looks like an HW issue.
> 
> It's unclear why this is happening or how to fix it, but as a quick
> work-around, this patch enables i734 errata work-around for omap2 and
> omap3 too. The errata work-around enables and disables the LCD output
> with a plane once when waking up the DSS IP, and it seems to resolve the
> omap3 problem too. It is unclear if omap2 has the same issue, but it
> probably has and the WA should have no side effects so it should be safe
> to enable on omap2 too.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkei...@ti.com>

Tested-by: Aaro Koskinen <aaro.koski...@iki.fi>

This fixes the LCD errors I'm seeing on N900 with v4.11, and I get a working
display.

A.

> ---
>  drivers/gpu/drm/omapdrm/dss/dispc.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
> b/drivers/gpu/drm/omapdrm/dss/dispc.c
> index 5ac0145fbae6..75e89707a70a 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -4004,6 +4004,11 @@ static const struct dispc_features 
> omap24xx_dispc_feats = {
>   .no_framedone_tv=   true,
>   .set_max_preload=   false,
>   .last_pixel_inc_missing =   true,
> + /*
> +  * HACK: see comment in omap34xx_rev1_0_dispc_feats. OMAP2 probably
> +  * has the same issue.
> +  */
> + .has_gamma_i734_bug =   true,
>  };
>  
>  static const struct dispc_features omap34xx_rev1_0_dispc_feats = {
> @@ -4025,6 +4030,13 @@ static const struct dispc_features 
> omap34xx_rev1_0_dispc_feats = {
>   .no_framedone_tv=   true,
>   .set_max_preload=   false,
>   .last_pixel_inc_missing =   true,
> + /*
> +  * HACK: OMAP3 doesn't have i734, but enabling the lcd output without
> +  * planes causes synclost flood. This only happens on initial enable,
> +  * not after that.
> +  * Piggyback on i734 flag until we understand this better.
> +  */
> + .has_gamma_i734_bug =   true,
>  };
>  
>  static const struct dispc_features omap34xx_rev3_0_dispc_feats = {
> @@ -4046,6 +4058,8 @@ static const struct dispc_features 
> omap34xx_rev3_0_dispc_feats = {
>   .no_framedone_tv=   true,
>   .set_max_preload=   false,
>   .last_pixel_inc_missing =   true,
> + /* HACK: see comment in omap34xx_rev1_0_dispc_feats */
> + .has_gamma_i734_bug =   true,
>  };
>  
>  static const struct dispc_features omap44xx_dispc_feats = {
> -- 
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 00/23] Nokia N950 display support

[Aaro Koskinen]

Hi,

On Tue, Mar 08, 2016 at 09:45:11PM +0100, Sebastian Reichel wrote:
> On Tue, Mar 08, 2016 at 08:39:08PM +0200, Aaro Koskinen wrote:
> > On Tue, Mar 08, 2016 at 05:39:32PM +0100, Sebastian Reichel wrote:
> > > This series adds support for the Nokia N950 display.
> > > Since the panel is using DSI command mode, it involves
> > > adding support for manually updated displays to
> > > omapdrm.
> > 
> > Works OK, but the picture seems to be upside down?
> 
> vertical, upside down is the native panel orientation.
> 
> > Also shouldn't the default orientation be landscape?
> 
> The N950 vendor kernel contains some code adding DSI
> rotation support with half-frame update mechnism to
> avoid tearing. It's quite complex and as far as I
> understand it also error-prone. Tomi knows more about
> that.

Ok, my comment was actually about fbcon (which doesn't need driver support
for rotation). But I guess there is no way to tell it what the default
should be, instead user needs to pass the correct rotation manually...

Anyway, for this series:

Tested-by: Aaro Koskinen 

A.

[PATCH 00/23] Nokia N950 display support

[Aaro Koskinen]

Hi,

On Tue, Mar 08, 2016 at 05:39:32PM +0100, Sebastian Reichel wrote:
> This series adds support for the Nokia N950 display.
> Since the panel is using DSI command mode, it involves
> adding support for manually updated displays to
> omapdrm.

Works OK, but the picture seems to be upside down? Also shouldn't the
default orientation be landscape?

A.

No more new fbdev drivers, please

[Aaro Koskinen]

Hi,

On Thu, Sep 24, 2015 at 03:27:01PM +0300, Tomi Valkeinen wrote:
> fbdev is (more or less) maintained, but it's a deprecated framework. All
> new Linux display drivers should be done on DRM.
> 
> So let's not add any more new fbdev drivers.
> 
> I will continue to maintain the current fbdev drivers, and I don't mind
> adding some new features to those current drivers, as long as the amount
> of code required to add the features stays sensible.
> 
> I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
> and the question is what to do with those.

I was still planning to work on xgifb as I need it on some systems for
the console.

A.

Build regressions/improvements in v4.1-rc1

[Aaro Koskinen]

Hi,

On Mon, Apr 27, 2015 at 12:03:32PM +0200, Geert Uytterhoeven wrote:
> > *** ERRORS ***
> >
> > 34 regressions:
> 
> The quiet days are over...
> 
> >   + /home/kisskb/slave/src/arch/mips/cavium-octeon/smp.c: error: passing 
> > argument 2 of 'cpumask_clear_cpu' discards 'volatile' qualifier from 
> > pointer target type [-Werror]:  => 242:2
> >   + /home/kisskb/slave/src/arch/mips/kernel/process.c: error: passing 
> > argument 2 of 'cpumask_test_cpu' discards 'volatile' qualifier from pointer 
> > target type [-Werror]:  => 52:2
> >   + /home/kisskb/slave/src/arch/mips/kernel/smp.c: error: passing argument 
> > 2 of 'cpumask_set_cpu' discards 'volatile' qualifier from pointer target 
> > type [-Werror]:  => 149:2, 211:2

For these there is a fix proposal: http://patchwork.linux-mips.org/patch/9828/

A.

Re: [PATCH 03/15] drm/nouveau: use mdelay instead of large udelay constants

[Aaro Koskinen]

Hi,

On Sat, Jun 01, 2013 at 12:22:40AM +0200, Arnd Bergmann wrote:
 ARM cannot handle udelay for more than 2 miliseconds, so we
   

 There's l missing here.

 should use mdelay instead for those.

Could this be handled inside ARM udelay() instead? Probably most of the
delay values are compile-time constants.

A.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 03/15] drm/nouveau: use mdelay instead of large udelay constants

[Aaro Koskinen]

Hi,

On Sat, Jun 01, 2013 at 12:22:40AM +0200, Arnd Bergmann wrote:
> ARM cannot handle udelay for more than 2 miliseconds, so we
   

 There's l missing here.

> should use mdelay instead for those.

Could this be handled inside ARM udelay() instead? Probably most of the
delay values are compile-time constants.

A.

Re: [PATCH] drm/nouveau: fix NULL ptr dereference from nv50_disp_intr()

[Aaro Koskinen]

Hi,

On Sun, Mar 24, 2013 at 12:56:30PM +0100, Maarten Lankhorst wrote:
 Op 23-03-13 12:47, Peter Hurley schreef:
  On Tue, 2013-03-19 at 11:13 -0400, Peter Hurley wrote:
  On vanilla 3.9.0-rc3, I get this 100% repeatable oops after login when
  the user X session is coming up:
  Perhaps I wasn't clear that this happens on every boot and is a
  regression from 3.8
 
  I'd be happy to help resolve this but time is of the essence; it would
  be a shame to have to revert all of this for 3.9
 
 Well it broke on my system too, so it was easy to fix.
 
 I didn't even need gdm to trigger it!
 
 8
 This fixes regression caused by 1d7c71a3e2f7 (drm/nouveau/disp: port vblank 
 handling to event interface),

This patch fixes the boot crashes also on my G5 iMac
(http://marc.info/?l=linux-kernelm=136285469916031w=2).

Tested-by: Aaro Koskinen aaro.koski...@iki.fi

A.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/nouveau: fix NULL ptr dereference from nv50_disp_intr()

[Aaro Koskinen]

Hi,

On Sun, Mar 24, 2013 at 12:56:30PM +0100, Maarten Lankhorst wrote:
> Op 23-03-13 12:47, Peter Hurley schreef:
> > On Tue, 2013-03-19 at 11:13 -0400, Peter Hurley wrote:
> >> On vanilla 3.9.0-rc3, I get this 100% repeatable oops after login when
> >> the user X session is coming up:
> > Perhaps I wasn't clear that this happens on every boot and is a
> > regression from 3.8
> >
> > I'd be happy to help resolve this but time is of the essence; it would
> > be a shame to have to revert all of this for 3.9
> 
> Well it broke on my system too, so it was easy to fix.
> 
> I didn't even need gdm to trigger it!
> 
> >8
> This fixes regression caused by 1d7c71a3e2f7 (drm/nouveau/disp: port vblank 
> handling to event interface),

This patch fixes the boot crashes also on my G5 iMac
(http://marc.info/?l=linux-kernel=136285469916031=2).

Tested-by: Aaro Koskinen 

A.

Re: linux 3.9-rc1: nouveau crash on PPC

[Aaro Koskinen]

Hi,

On Sat, Mar 09, 2013 at 08:44:31PM +0200, Aaro Koskinen wrote:
 There's nouveau crash during boot with 3.9-rc1 on iMac G5 (nVidia GeForce
 FX 5200 Ultra). This happens also with current mainline kernel HEAD
 (0aefda3e8188ad71168bd32152d41b3d72f04087).
 
 git bisect tells the first bad commit is
 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b (drm/nouveau/disp: port vblank
 handling to event interface).
 
 The crash is (manually copied from screen):
 
 [...]
 
 Unable to handle kernel paging request for data at address 0x1
 
 call trace:
 nouveau_event_trigger

The cause is event handling linked lists getting corrupted.

I'm not sure how that code is intented to work, but with the below HACK
I can at least boot the iMac without crashing, and get a working display:

diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index 6d01e0f..ab8d6c7 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -29,7 +29,7 @@ nouveau_event_put_locked(struct nouveau_event *event, int 
index,
 {
if (!--event-index[index].refs)
event-disable(event, index);
-   list_del(handler-head);
+   list_del(handler-heads[index]);
 }
 
 void
@@ -39,7 +39,7 @@ nouveau_event_put(struct nouveau_event *event, int index,
unsigned long flags;
 
spin_lock_irqsave(event-lock, flags);
-   if (index  event-index_nr)
+   if (index  ARRAY_SIZE(handler-heads)  index  event-index_nr)
nouveau_event_put_locked(event, index, handler);
spin_unlock_irqrestore(event-lock, flags);
 }
@@ -51,8 +51,8 @@ nouveau_event_get(struct nouveau_event *event, int index,
unsigned long flags;
 
spin_lock_irqsave(event-lock, flags);
-   if (index  event-index_nr) {
-   list_add(handler-head, event-index[index].list);
+   if (index  ARRAY_SIZE(handler-heads)  index  event-index_nr) {
+   list_add(handler-heads[index], event-index[index].list);
if (!event-index[index].refs++)
event-enable(event, index);
}
@@ -69,7 +69,7 @@ nouveau_event_trigger(struct nouveau_event *event, int index)
return;
 
spin_lock_irqsave(event-lock, flags);
-   list_for_each_entry_safe(handler, temp, event-index[index].list, 
head) {
+   list_for_each_entry_safe(handler, temp, event-index[index].list, 
heads[index]) {
if (handler-func(handler, index) == NVKM_EVENT_DROP) {
nouveau_event_put_locked(event, index, handler);
}
diff --git a/drivers/gpu/drm/nouveau/core/include/core/event.h 
b/drivers/gpu/drm/nouveau/core/include/core/event.h
index 9e09440..ba52172 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/event.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/event.h
@@ -6,7 +6,7 @@
 #define NVKM_EVENT_KEEP 1
 
 struct nouveau_eventh {
-   struct list_head head;
+   struct list_head heads[2];
int (*func)(struct nouveau_eventh *, int index);
 };
 
A.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

linux 3.9-rc1: nouveau crash on PPC

[Aaro Koskinen]

Hi,

On Sat, Mar 09, 2013 at 08:44:31PM +0200, Aaro Koskinen wrote:
> There's nouveau crash during boot with 3.9-rc1 on iMac G5 (nVidia GeForce
> FX 5200 Ultra). This happens also with current mainline kernel HEAD
> (0aefda3e8188ad71168bd32152d41b3d72f04087).
> 
> git bisect tells the first bad commit is
> 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b (drm/nouveau/disp: port vblank
> handling to event interface).
> 
> The crash is (manually copied from screen):
> 
> [...]
> 
> Unable to handle kernel paging request for data at address 0x1
> 
> call trace:
> nouveau_event_trigger

The cause is event handling linked lists getting corrupted.

I'm not sure how that code is intented to work, but with the below HACK
I can at least boot the iMac without crashing, and get a working display:

diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index 6d01e0f..ab8d6c7 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -29,7 +29,7 @@ nouveau_event_put_locked(struct nouveau_event *event, int 
index,
 {
if (!--event->index[index].refs)
event->disable(event, index);
-   list_del(>head);
+   list_del(>heads[index]);
 }

 void
@@ -39,7 +39,7 @@ nouveau_event_put(struct nouveau_event *event, int index,
unsigned long flags;

spin_lock_irqsave(>lock, flags);
-   if (index < event->index_nr)
+   if (index < ARRAY_SIZE(handler->heads) && index < event->index_nr)
nouveau_event_put_locked(event, index, handler);
spin_unlock_irqrestore(>lock, flags);
 }
@@ -51,8 +51,8 @@ nouveau_event_get(struct nouveau_event *event, int index,
unsigned long flags;

spin_lock_irqsave(>lock, flags);
-   if (index < event->index_nr) {
-   list_add(>head, >index[index].list);
+   if (index < ARRAY_SIZE(handler->heads) && index < event->index_nr) {
+   list_add(>heads[index], >index[index].list);
if (!event->index[index].refs++)
event->enable(event, index);
}
@@ -69,7 +69,7 @@ nouveau_event_trigger(struct nouveau_event *event, int index)
return;

spin_lock_irqsave(>lock, flags);
-   list_for_each_entry_safe(handler, temp, >index[index].list, 
head) {
+   list_for_each_entry_safe(handler, temp, >index[index].list, 
heads[index]) {
if (handler->func(handler, index) == NVKM_EVENT_DROP) {
nouveau_event_put_locked(event, index, handler);
}
diff --git a/drivers/gpu/drm/nouveau/core/include/core/event.h 
b/drivers/gpu/drm/nouveau/core/include/core/event.h
index 9e09440..ba52172 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/event.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/event.h
@@ -6,7 +6,7 @@
 #define NVKM_EVENT_KEEP 1

 struct nouveau_eventh {
-   struct list_head head;
+   struct list_head heads[2];
int (*func)(struct nouveau_eventh *, int index);
 };

A.

linux 3.9-rc1: nouveau crash on PPC

[Aaro Koskinen]

Hi,

There's nouveau crash during boot with 3.9-rc1 on iMac G5 (nVidia GeForce
FX 5200 Ultra). This happens also with current mainline kernel HEAD
(0aefda3e8188ad71168bd32152d41b3d72f04087).

git bisect tells the first bad commit is
1d7c71a3e2f77336df536855b0efd2dc5bdeb41b (drm/nouveau/disp: port vblank
handling to event interface).

The crash is (manually copied from screen):

[...]

Unable to handle kernel paging request for data at address 0x1

call trace:
nouveau_event_trigger
nv04_disp_intr
nouveau_mc_intr
nouveau_irq_handler

[...]

I also tried to capture it with netconsole, and got this much:

[   23.114208] nouveau  [  DEVICE][:f0:10.0] BOOT0  : 0x034900b1
[   23.114257] nouveau  [  DEVICE][:f0:10.0] Chipset: NV34 (NV34)
[   23.114266] nouveau  [  DEVICE][:f0:10.0] Family : NV30
[   23.114672] nouveau  [   VBIOS][:f0:10.0] checking OpenFirmware for 
image...
[   23.114712] nouveau  [   VBIOS][:f0:10.0] ... checksum invalid
[   23.114720] nouveau  [   VBIOS][:f0:10.0] checking PRAMIN for image...
[   23.114754] nouveau  [   VBIOS][:f0:10.0] ... signature not found
[   23.114761] nouveau  [   VBIOS][:f0:10.0] checking PROM for image...
[   23.114845] nouveau  [   VBIOS][:f0:10.0] ... signature not found
[   23.114853] nouveau  [   VBIOS][:f0:10.0] checking ACPI for image...
[   23.114862] nouveau  [   VBIOS][:f0:10.0] ... signature not found
[   23.114881] nouveau  [   VBIOS][:f0:10.0] checking PCIROM for image...
[   23.114930] nouveau :f0:10.0: Invalid ROM contents
[   23.114946] nouveau  [   VBIOS][:f0:10.0] ... signature not found
[   23.114976] nouveau  [   VBIOS][:f0:10.0] using image from OpenFirmware
[   23.114987] nouveau  [   VBIOS][:f0:10.0] BMP version 5.26
[   23.115035] nouveau  [   VBIOS][:f0:10.0] version 04.34.20.18.00
[   23.134608] nouveau W[   VBIOS][:f0:10.0] unknown i2c type 3
[   23.134637] nouveau W[   VBIOS][:f0:10.0] unknown i2c type 3
[   23.136488] nouveau W[  PTIMER][:f0:10.0] unknown input clock freq
[   23.136536] nouveau  [ PFB][:f0:10.0] RAM type: DDR1
[   23.136544] nouveau  [ PFB][:f0:10.0] RAM size: 32 MiB
[   23.136552] nouveau  [ PFB][:f0:10.0]ZCOMP: 0 tags
[   23.150773] [TTM] Zone  kernel: Available graphics memory: 744988 kiB
[   23.150800] [TTM] Initializing pool allocator
[   23.150882] nouveau  [ DRM] VRAM: 31 MiB
[   23.150890] nouveau  [ DRM] GART: 128 MiB
[   23.150927] nouveau  [ DRM] BMP version 5.38
[   23.150937] nouveau  [ DRM] DCB version 2.2
[   23.150971] nouveau  [ DRM] DCB outp 00: 01000122 0004
[   23.150981] nouveau  [ DRM] DCB outp 01: 02010200 11b088b8
[   23.150988] nouveau  [ DRM] DCB outp 02: 02010201 11b00703
[   23.151040] nouveau  [ DRM] Loading NV17 power sequencing microcode
[   23.170180] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[   23.170212] [drm] No driver support for vblank timestamp query.
[   23.170277] nouveau E[ DRM] Pixel clock comparison table not found
[   23.171010] nouveau  [ DRM] 0 available performance level(s)
[   23.171028] nouveau  [ DRM] c: core 241MHz memory 475MHz
[   23.177822] nouveau  [ DRM] MM: using M2MF for buffer copies
[   23.177917] nouveau  [ DRM] Setting dpms mode 3 on TV encoder (output 2)
[   23.285783] nouveau  [ DRM] allocated 1680x1050 fb: 0x9000, bo 
c00056d52c00
[   23.306569] nouveau E[ DRM] Pixel clock comparison table not found
[   23.317565] Console: switching to colour frame buffer device 210x65
[   23.321370] nouveau :f0:10.0: fb0: nouveaufb frame buffer device
[   23.321386] nouveau :f0:10.0: registered panic notifier
[   23.321444] [drm] Initialized nouveau 1.1.0 20120801 for :f0:10.0 on 
minor 0
[   23.329860] Unable to handle kernel paging request for data at address 
0x1
[   23.329918] Faulting instruction address: 0xd0801394
[   23.329939] Oops: Kernel access of bad area, sig: 11 [#1]
[   23.329953] PREEMPT PowerMac
[   23.329982] Modules linked in: nouveau ttm drm_kms_helper
[   23.330035] NIP: d0801394 LR: d08013a8 CTR: c00178e0
[   23.330052] REGS: cfff78b0 TRAP: 0300   Not tainted  
(3.9.0-rc1-imac-00277-g0aefda3-dirty)
[   23.330065] MSR: 90009032 SF,HV,EE,ME,IR,DR,RI  CR: 2884  XER: 

[   23.330174] SOFTE: 0
[   23.330187] DAR: 0001, DSISR: 4000
[   23.330202] TASK = c0805aa0[0] 'swapper' THREAD: c0894000
GPR00: d08013a8 cfff7b30 d09272c0 c00056de5458 
GPR04:   0002  
GPR08: [   24.321933] Kernel panic - not syncing: Fatal exception in interrupt
[   24.321951] drm_kms_helper: panic occurred, switching back to text console
[   24.322013] [ cut here ]
[   24.322029] WARNING: at drivers/gpu/drm/drm_crtc.c:82
[   24.322041] Modules linked in: nouveau ttm 

linux 3.9-rc1: nouveau crash on PPC

[Aaro Koskinen]

Hi,

There's nouveau crash during boot with 3.9-rc1 on iMac G5 (nVidia GeForce
FX 5200 Ultra). This happens also with current mainline kernel HEAD
(0aefda3e8188ad71168bd32152d41b3d72f04087).

git bisect tells the first bad commit is
1d7c71a3e2f77336df536855b0efd2dc5bdeb41b (drm/nouveau/disp: port vblank
handling to event interface).

The crash is (manually copied from screen):

[...]

Unable to handle kernel paging request for data at address 0x1

call trace:
nouveau_event_trigger
nv04_disp_intr
nouveau_mc_intr
nouveau_irq_handler

[...]

I also tried to capture it with netconsole, and got this much:

[   23.114208] nouveau  [  DEVICE][:f0:10.0] BOOT0  : 0x034900b1
[   23.114257] nouveau  [  DEVICE][:f0:10.0] Chipset: NV34 (NV34)
[   23.114266] nouveau  [  DEVICE][:f0:10.0] Family : NV30
[   23.114672] nouveau  [   VBIOS][:f0:10.0] checking OpenFirmware for 
image...
[   23.114712] nouveau  [   VBIOS][:f0:10.0] ... checksum invalid
[   23.114720] nouveau  [   VBIOS][:f0:10.0] checking PRAMIN for image...
[   23.114754] nouveau  [   VBIOS][:f0:10.0] ... signature not found
[   23.114761] nouveau  [   VBIOS][:f0:10.0] checking PROM for image...
[   23.114845] nouveau  [   VBIOS][:f0:10.0] ... signature not found
[   23.114853] nouveau  [   VBIOS][:f0:10.0] checking ACPI for image...
[   23.114862] nouveau  [   VBIOS][:f0:10.0] ... signature not found
[   23.114881] nouveau  [   VBIOS][:f0:10.0] checking PCIROM for image...
[   23.114930] nouveau :f0:10.0: Invalid ROM contents
[   23.114946] nouveau  [   VBIOS][:f0:10.0] ... signature not found
[   23.114976] nouveau  [   VBIOS][:f0:10.0] using image from OpenFirmware
[   23.114987] nouveau  [   VBIOS][:f0:10.0] BMP version 5.26
[   23.115035] nouveau  [   VBIOS][:f0:10.0] version 04.34.20.18.00
[   23.134608] nouveau W[   VBIOS][:f0:10.0] unknown i2c type 3
[   23.134637] nouveau W[   VBIOS][:f0:10.0] unknown i2c type 3
[   23.136488] nouveau W[  PTIMER][:f0:10.0] unknown input clock freq
[   23.136536] nouveau  [ PFB][:f0:10.0] RAM type: DDR1
[   23.136544] nouveau  [ PFB][:f0:10.0] RAM size: 32 MiB
[   23.136552] nouveau  [ PFB][:f0:10.0]ZCOMP: 0 tags
[   23.150773] [TTM] Zone  kernel: Available graphics memory: 744988 kiB
[   23.150800] [TTM] Initializing pool allocator
[   23.150882] nouveau  [ DRM] VRAM: 31 MiB
[   23.150890] nouveau  [ DRM] GART: 128 MiB
[   23.150927] nouveau  [ DRM] BMP version 5.38
[   23.150937] nouveau  [ DRM] DCB version 2.2
[   23.150971] nouveau  [ DRM] DCB outp 00: 01000122 0004
[   23.150981] nouveau  [ DRM] DCB outp 01: 02010200 11b088b8
[   23.150988] nouveau  [ DRM] DCB outp 02: 02010201 11b00703
[   23.151040] nouveau  [ DRM] Loading NV17 power sequencing microcode
[   23.170180] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[   23.170212] [drm] No driver support for vblank timestamp query.
[   23.170277] nouveau E[ DRM] Pixel clock comparison table not found
[   23.171010] nouveau  [ DRM] 0 available performance level(s)
[   23.171028] nouveau  [ DRM] c: core 241MHz memory 475MHz
[   23.177822] nouveau  [ DRM] MM: using M2MF for buffer copies
[   23.177917] nouveau  [ DRM] Setting dpms mode 3 on TV encoder (output 2)
[   23.285783] nouveau  [ DRM] allocated 1680x1050 fb: 0x9000, bo 
c00056d52c00
[   23.306569] nouveau E[ DRM] Pixel clock comparison table not found
[   23.317565] Console: switching to colour frame buffer device 210x65
[   23.321370] nouveau :f0:10.0: fb0: nouveaufb frame buffer device
[   23.321386] nouveau :f0:10.0: registered panic notifier
[   23.321444] [drm] Initialized nouveau 1.1.0 20120801 for :f0:10.0 on 
minor 0
[   23.329860] Unable to handle kernel paging request for data at address 
0x1
[   23.329918] Faulting instruction address: 0xd0801394
[   23.329939] Oops: Kernel access of bad area, sig: 11 [#1]
[   23.329953] PREEMPT PowerMac
[   23.329982] Modules linked in: nouveau ttm drm_kms_helper
[   23.330035] NIP: d0801394 LR: d08013a8 CTR: c00178e0
[   23.330052] REGS: cfff78b0 TRAP: 0300   Not tainted  
(3.9.0-rc1-imac-00277-g0aefda3-dirty)
[   23.330065] MSR: 90009032   CR: 2884  XER: 

[   23.330174] SOFTE: 0
[   23.330187] DAR: 0001, DSISR: 4000
[   23.330202] TASK = c0805aa0[0] 'swapper' THREAD: c0894000
GPR00: d08013a8 cfff7b30 d09272c0 c00056de5458 
GPR04:   0002  
GPR08: [   24.321933] Kernel panic - not syncing: Fatal exception in interrupt
[   24.321951] drm_kms_helper: panic occurred, switching back to text console
[   24.322013] [ cut here ]
[   24.322029] WARNING: at drivers/gpu/drm/drm_crtc.c:82
[   24.322041] Modules linked in: nouveau ttm 

[RESEND PATCH] drm/nouveau: fix init with agpgart-uninorth

[Aaro Koskinen]

Check that the AGP aperture can be mapped. This follows a similar change
done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if
the aperture can be mapped by the CPU.).

The patch fixes the following error seen on G5 iMac:

nouveau E[ DRM] failed to create kernel channel, -12

Reviewed-by: Michel D?nzer 
Signed-off-by: Aaro Koskinen 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 5614c89..69d7b1d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1276,7 +1276,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, 
struct ttm_mem_reg *mem)
if (drm->agp.stat == ENABLED) {
mem->bus.offset = mem->start << PAGE_SHIFT;
mem->bus.base = drm->agp.base;
-   mem->bus.is_iomem = true;
+   mem->bus.is_iomem = !dev->agp->cant_use_aperture;
}
 #endif
break;
-- 
1.7.10.4

[PATCH] drm/nouveau: fix init with agpgart-uninorth

[Aaro Koskinen]

Check that the AGP aperture can be mapped. This follows a similar change
done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if
the aperture can be mapped by the CPU.).

The patch fixes the following error seen on G5 iMac:

nouveau E[ DRM] failed to create kernel channel, -12

Signed-off-by: Aaro Koskinen 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 35ac57f..5f0e7ef 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1279,7 +1279,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, 
struct ttm_mem_reg *mem)
if (drm->agp.stat == ENABLED) {
mem->bus.offset = mem->start << PAGE_SHIFT;
mem->bus.base = drm->agp.base;
-   mem->bus.is_iomem = true;
+   mem->bus.is_iomem = !dev->agp->cant_use_aperture;
}
 #endif
break;
-- 
1.7.10.4

[PATCH] drm/nouveau: fix init with agpgart-uninorth

[Aaro Koskinen]

Check that the AGP aperture can be mapped. This follows a similar change
done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if
the aperture can be mapped by the CPU.).

The patch fixes the following error seen on G5 iMac:

nouveau E[ DRM] failed to create kernel channel, -12

Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
 drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 35ac57f..5f0e7ef 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1279,7 +1279,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, 
struct ttm_mem_reg *mem)
if (drm-agp.stat == ENABLED) {
mem-bus.offset = mem-start  PAGE_SHIFT;
mem-bus.base = drm-agp.base;
-   mem-bus.is_iomem = true;
+   mem-bus.is_iomem = !dev-agp-cant_use_aperture;
}
 #endif
break;
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel