[linux-sunxi] Re: [PATCH v5 3/7] drm: sun4i: dsi: Convert to bridge driver
> handle the DSI
> > > > > > > > > bindings and look for a panel or bridge not only through the
> > > > > > > > > OF graph,
> > > > > > > > > but also on the child nodes
> > > > > > > >
> > > > > > > > Okay. I need to check this.
> > > > > > >
> > > > > > > devm_drm_of_get_bridge is not working with legacy binding like
> > > > > > > the one
> > > > > > > used in sun6i dsi
> > > > > >
> > > > > > There's nothing legacy about it.
> > > > >
> > > > > What I'm mean legacy here with current binding used in sun6i-dsi like
> > > > > this.
> > > > >
> > > > > &dsi {
> > > > > vcc-dsi-supply = <®_dcdc1>; /* VCC-DSI */
> > > > > status = "okay";
> > > > >
> > > > > panel@0 {
> > > > >compatible = "bananapi,s070wv20-ct16-icn6211";
> > > > >reg = <0>;
> > > > >reset-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /*
> > > > > LCD-RST: PL5 */
> > > > > enable-gpios = <&pio 1 7 GPIO_ACTIVE_HIGH>; /*
> > > > > LCD-PWR-EN: PB7 */
> > > > > backlight = <&backlight>;
> > > > > };
> > > > > };
> > > >
> > > > Yes, I know, it's the generic DSI binding. It's still not legacy.
> > > >
> > > > > devm_drm_of_get_bridge cannot find the device with above binding and
> > > > > able to find the device with below binding.
> > > > >
> > > > > &dsi {
> > > > >vcc-dsi-supply = <®_dcdc1>; /* VCC-DSI */
> > > > >status = "okay";
> > > > >
> > > > > ports {
> > > > > #address-cells = <1>;
> > > > > #size-cells = <0>;
> > > > >
> > > > >dsi_out: port@0 {
> > > > >reg = <0>;
> > > > >
> > > > > dsi_out_bridge: endpoint {
> > > > > remote-endpoint = <&bridge_out_dsi>;
> > > > > };
> > > > >};
> > > > > };
> > > > >
> > > > > panel@0 {
> > > > > compatible = "bananapi,s070wv20-ct16-icn6211";
> > > > > reg = <0>;
> > > > > reset-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* LCD-RST:
> > > > > PL5 */
> > > > > enable-gpios = <&pio 1 7 GPIO_ACTIVE_HIGH>; /*
> > > > > LCD-PWR-EN: PB7 */
> > > > > backlight = <&backlight>;
> > > > >
> > > > > port {
> > > > > bridge_out_dsi: endpoint {
> > > > > remote-endpoint = <&dsi_out_bridge>;
> > > > > };
> > > > > };
> > > > >};
> > > > > };
> > > >
> > > > Yes, I know, and that's because ...
> > >
> > > Okay. I will use find panel and bridge separately instead of
> > > devm_drm_of_get_bridge in version patches.
> >
> > That's not been my point, at all?
> >
> > I mean, that whole discussion has been because you shouldn't do that.
> >
> > > >
> > > > > >
> > > > > > > https://patchwork.kernel.org/project/dri-devel/patch/20211122065223.88059-6-ja...@amarulasolutions.com/
> > > > > > >
> > > > > > > dsi->next_bridge = devm_drm_of_get_bridge(dsi->dev,
> > > > > > > dsi->dev->of_node, 0, 0);
> > > > > > > if (IS_ERR(dsi->next_bridge))
> > > > > > >return PTR_ERR(dsi->next_bridge);
> > > > > > >
> > > > > > > It is only working if we have ports on the pipeline, something
> > > > > > > like this
> > > > > > > https://patchwork.kernel.org/project/dri-devel/patch/20210214194102.126146-8-ja...@amarulasolutions.com/
> > > > > > >
> > > > > > > Please have a look and let me know if I miss anything?
> > > > > >
> > > > > > Yes, you're missing the answer you quoted earlier:
> > > > >
> > > > > Yes, I'm trying to resolve the comment one after another. Will get
> > > > > back.
> > > >
> > > > ... You've ignored that comment.
> > >
> > > Not understand which comment you mean. There are few about bridge
> > > conversion details, I will send my comments.
> >
> > The one that got quoted there and you removed. For reference:
> >
> > > Then drm_of_find_panel_or_bridge needs to be adjusted to handle the DSI
> > > bindings and look for a panel or bridge not only through the OF graph,
> > > but also on the child nodes
> >
> > devm_drm_of_get_bridge uses drm_of_find_panel_or_bridge under the hood,
> > so of course it won't find it if drm_of_find_panel_or_bridge doesn't.
> > You need to modify drm_of_find_panel_or_bridge to also look for child
> > devices and see if there's a panel or bridge registered for that child
> > node. Then devm_drm_of_get_bridge will work as you intend it to.
>
> Got it now, I will make necessary changes.
>
> Thanks,
> Jagan.
>
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/CAOf5uw%3DQF7XMbYT4pyZBTTO87TRLzVmYH2HvX%3DjCg_QpNGN1LA%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v2 3/3] video: sunxi_display: Convert to DM_VIDEO
}
> > > /* Fall back to EDID in case HPD failed */
> > > if (edid && !hdmi_present) {
> > > - if (sunxi_hdmi_edid_get_mode(&custom, false) == 0) {
> > > + if (sunxi_hdmi_edid_get_mode(sunxi_display,
> > > &custom, false) == 0) {
> > > mode = &custom;
> > > hdmi_present = true;
> > > }
> > > @@ -1114,38 +1126,39 @@ void *video_hw_init(void)
> > > /* Shut down when display was not found */
> > > if ((hpd || edid) && !hdmi_present) {
> > > sunxi_hdmi_shutdown();
> > > - sunxi_display.monitor =
> > > sunxi_get_default_mon(false);
> > > + sunxi_display->monitor =
> > > sunxi_get_default_mon(false);
> > > } /* else continue with hdmi/dvi without a cable connected
> > > */
> > > }
> > > #endif
> > >
> > > - switch (sunxi_display.monitor) {
> > > + switch (sunxi_display->monitor) {
> > > case sunxi_monitor_none:
> > > - return NULL;
> > > + printf("Unknown monitor\n");
> > > + return -EINVAL;
> > > case sunxi_monitor_dvi:
> > > case sunxi_monitor_hdmi:
> > > if (!sunxi_has_hdmi()) {
> > > printf("HDMI/DVI not supported on this board\n");
> > > - sunxi_display.monitor = sunxi_monitor_none;
> > > - return NULL;
> > > + sunxi_display->monitor = sunxi_monitor_none;
> > > + return -EINVAL;
> > > }
> > > break;
> > > case sunxi_monitor_lcd:
> > > if (!sunxi_has_lcd()) {
> > > printf("LCD not supported on this board\n");
> > > - sunxi_display.monitor = sunxi_monitor_none;
> > > - return NULL;
> > > + sunxi_display->monitor = sunxi_monitor_none;
> > > + return -EINVAL;
> > > }
> > > - sunxi_display.depth = video_get_params(&custom, lcd_mode);
> > > + sunxi_display->depth = video_get_params(&custom, lcd_mode);
> > > mode = &custom;
> > > break;
> > > case sunxi_monitor_vga:
> > > if (!sunxi_has_vga()) {
> > > printf("VGA not supported on this board\n");
> > > - sunxi_display.monitor = sunxi_monitor_none;
> > > - return NULL;
> > > + sunxi_display->monitor = sunxi_monitor_none;
> > > + return -EINVAL;
> > > }
> > > - sunxi_display.depth = 18;
> > > + sunxi_display->depth = 18;
> > > break;
> > > case sunxi_monitor_composite_pal:
> > > case sunxi_monitor_composite_ntsc:
> > > @@ -1153,85 +1166,103 @@ void *video_hw_init(void)
> > > case sunxi_monitor_composite_pal_nc:
> > > if (!sunxi_has_composite()) {
> > > printf("Composite video not supported on this
> > > board\n");
> > > - sunxi_display.monitor = sunxi_monitor_none;
> > > - return NULL;
> > > + sunxi_display->monitor = sunxi_monitor_none;
> > > + return -EINVAL;
> > > }
> > > - if (sunxi_display.monitor == sunxi_monitor_composite_pal ||
> > > - sunxi_display.monitor == sunxi_monitor_composite_pal_nc)
> > > + if (sunxi_display->monitor == sunxi_monitor_composite_pal ||
> > > + sunxi_display->monitor ==
> > > sunxi_monitor_composite_pal_nc)
> > > mode = &composite_video_modes[0];
> > > else
> > > mode = &composite_video_modes[1];
> > > - sunxi_display.depth = 24;
> > > + sunxi_display->depth = 24;
> > > break;
> > > }
> > >
> > > /* Yes these defaults are quite high, overscan on composite
> > > sucks... */
> > > if (overscan_x == -1)
> > > - overscan_x = sunxi_is_composite() ? 32 : 0;
> > > + overscan_x = sunxi_is_composite(sunxi_display->monitor) ?
> > > 32 : 0;
> > > if (overscan_y == -1)
> > > - overscan_y = sunxi_is_composite() ? 20 : 0;
> > > + overscan_y = sunxi_is_composite(sunxi_display->monitor) ?
> > > 20 : 0;
> > >
> > > - sunxi_display.fb_size =
> > > - (mode->xres * mode->yres * 4 + 0xfff) & ~0xfff;
> > > + sunxi_display->fb_size = plat->size;
> > > overscan_offset = (overscan_y * mode->xres + overscan_x) * 4;
> > > /* We want to keep the fb_base for simplefb page aligned, where as
> > >* the sunxi dma engines will happily accept an unaligned address.
> > > */
> > > if (overscan_offset)
> > > - sunxi_display.fb_size += 0x1000;
> > > -
> > > - if (sunxi_display.fb_size > CONFIG_SUNXI_MAX_FB_SIZE) {
> > > - printf("Error need %dkB for fb, but only %dkB is
> > > reserved\n",
> > > -sunxi_display.fb_size >> 10,
> > > -CONFIG_SUNXI_MAX_FB_SIZE >> 10);
> > > - return NULL;
> > > - }
> > > + sunxi_display->fb_size += 0x1000;
> > >
> > > printf("Setting up a %dx%d%s %s console (overscan %dx%d)\n",
> > > mode->xres, mode->yres,
> > > (mode->vmode == FB_VMODE_INTERLACED) ? "i" : "",
> > > -sunxi_get_mon_desc(sunxi_display.monitor),
> > > +sunxi_get_mon_desc(sunxi_display->monitor),
> > > overscan_x, overscan_y);
> > >
> > > - gd->fb_base = gd->bd->bi_dram[0].start +
> > > - gd->bd->bi_dram[0].size - sunxi_display.fb_size;
> > > + sunxi_display->fb_addr = plat->base;
> > > sunxi_engines_init();
> > >
> > > #ifdef CONFIG_EFI_LOADER
> > > - efi_add_memory_map(gd->fb_base, sunxi_display.fb_size,
> > > + efi_add_memory_map(sunxi_display->fb_addr, sunxi_display->fb_size,
> > > EFI_RESERVED_MEMORY_TYPE);
> > > #endif
> > >
> > > - fb_dma_addr = gd->fb_base - CONFIG_SYS_SDRAM_BASE;
> > > - sunxi_display.fb_addr = gd->fb_base;
> > > + fb_dma_addr = sunxi_display->fb_addr - CONFIG_SYS_SDRAM_BASE;
> > > if (overscan_offset) {
> > > fb_dma_addr += 0x1000 - (overscan_offset & 0xfff);
> > > - sunxi_display.fb_addr += (overscan_offset + 0xfff) & ~0xfff;
> > > - memset((void *)gd->fb_base, 0, sunxi_display.fb_size);
> > > - flush_cache(gd->fb_base, sunxi_display.fb_size);
> > > + sunxi_display->fb_addr += (overscan_offset + 0xfff) &
> > > ~0xfff;
> > > + memset((void *)sunxi_display->fb_addr, 0,
> > > sunxi_display->fb_size);
> > > + flush_cache(sunxi_display->fb_addr, sunxi_display->fb_size);
> > > }
> > > - sunxi_mode_set(mode, fb_dma_addr);
> > > + sunxi_mode_set(sunxi_display, mode, fb_dma_addr);
> > >
> > > /*
> > >* These are the only members of this structure that are used. All
> > > the
> > >* others are driver specific. The pitch is stored in plnSizeX.
> > >*/
> > > - graphic_device->frameAdrs = sunxi_display.fb_addr;
> > > - graphic_device->gdfIndex = GDF_32BIT_X888RGB;
> > > - graphic_device->gdfBytesPP = 4;
> > > - graphic_device->winSizeX = mode->xres - 2 * overscan_x;
> > > - graphic_device->winSizeY = mode->yres - 2 * overscan_y;
> > > - graphic_device->plnSizeX = mode->xres * graphic_device->gdfBytesPP;
> > > -
> > > - return graphic_device;
> > > + uc_priv->bpix = VIDEO_BPP32;
> > > + uc_priv->xsize = mode->xres;
> > > + uc_priv->ysize = mode->yres;
> > > +
> > > + video_set_flush_dcache(dev, 1);
> >
> > This is new. You should explain in a separate patch why the flush_cache
> > above isn't enough.
>
> This is new and but required when for DM_VIDEO conversion.
> video-uclass has a common way to flush video via video_sync so the
> driver has to trigger this flush and without this, the vidconsole
> shows inconsistent characters.
>
> Jagan.
>
>
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/CAOf5uwkRb0-3ZuF9mwkE4tVXsvS5U4RUym-JgnoDsiBgQTH%3DBQ%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
Hi Maxime On Wed, Aug 28, 2019 at 3:03 PM Maxime Ripard wrote: > > Hi, > > On Thu, Aug 15, 2019 at 02:25:57PM +0200, Michael Nazzareno Trimarchi wrote: > > On Tue, Aug 13, 2019 at 8:05 AM Maxime Ripard > > wrote: > > > On Mon, Jul 29, 2019 at 08:59:04AM +0200, Michael Nazzareno Trimarchi > > > wrote: > > > > Hi > > > > > > > > On Wed, Jul 24, 2019 at 11:05 AM Maxime Ripard > > > > wrote: > > > > > > > > > > On Mon, Jul 22, 2019 at 03:51:04PM +0530, Jagan Teki wrote: > > > > > > Hi Maxime, > > > > > > > > > > > > On Sat, Jul 20, 2019 at 3:02 PM Maxime Ripard > > > > > > wrote: > > > > > > > > > > > > > > On Sat, Jul 20, 2019 at 12:46:27PM +0530, Jagan Teki wrote: > > > > > > > > On Sat, Jul 20, 2019 at 12:28 PM Maxime Ripard > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Thu, Jul 11, 2019 at 07:43:16PM +0200, Michael Nazzareno > > > > > > > > > Trimarchi wrote: > > > > > > > > > > > > tcon-pixel clock is the rate that you want to achive on > > > > > > > > > > > > display side > > > > > > > > > > > > and if you have 4 lanes 32bit or lanes and different > > > > > > > > > > > > bit number that > > > > > > > > > > > > you need to have a clock that is able to put outside > > > > > > > > > > > > bits and speed > > > > > > > > > > > > equal to pixel-clock * bits / lanes. so If you want a > > > > > > > > > > > > pixel-clock of > > > > > > > > > > > > 40 mhz and you have 32bits and 4 lanes you need to have > > > > > > > > > > > > a clock of > > > > > > > > > > > > 40 * 32 / 4 in no-burst mode. I think that this is done > > > > > > > > > > > > but most of > > > > > > > > > > > > the display. > > > > > > > > > > > > > > > > > > > > > > So this is what the issue is then? > > > > > > > > > > > > > > > > > > > > > > This one does make sense, and you should just change the > > > > > > > > > > > rate in the > > > > > > > > > > > call to clk_set_rate in sun4i_tcon0_mode_set_cpu. > > > > > > > > > > > > > > > > > > > > > > I'm still wondering why that hasn't been brought up in > > > > > > > > > > > either the > > > > > > > > > > > discussion or the commit log before though. > > > > > > > > > > > > > > > > > > > > > Something like this? > > > > > > > > > > > > > > > > > > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 > > > > > > > > > > +++- > > > > > > > > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 2 -- > > > > > > > > > > 2 files changed, 11 insertions(+), 11 deletions(-) > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c > > > > > > > > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c > > > > > > > > > > index 64c43ee6bd92..42560d5c327c 100644 > > > > > > > > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c > > > > > > > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c > > > > > > > > > > @@ -263,10 +263,11 @@ static int > > > > > > > > > > sun4i_tcon_get_clk_delay(const struct > > > > > > > > > > drm_display_mode *mode, > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > static void sun4i_tcon0_mode_set_common(struct sun4i_tcon > > > > > > > > > > *tcon, > > > > > > > > > > - const struct > > > > > >
[linux-sunxi] Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
Hi Maxime
On Tue, Aug 13, 2019 at 8:05 AM Maxime Ripard wrote:
>
> On Mon, Jul 29, 2019 at 08:59:04AM +0200, Michael Nazzareno Trimarchi wrote:
> > Hi
> >
> > On Wed, Jul 24, 2019 at 11:05 AM Maxime Ripard
> > wrote:
> > >
> > > On Mon, Jul 22, 2019 at 03:51:04PM +0530, Jagan Teki wrote:
> > > > Hi Maxime,
> > > >
> > > > On Sat, Jul 20, 2019 at 3:02 PM Maxime Ripard
> > > > wrote:
> > > > >
> > > > > On Sat, Jul 20, 2019 at 12:46:27PM +0530, Jagan Teki wrote:
> > > > > > On Sat, Jul 20, 2019 at 12:28 PM Maxime Ripard
> > > > > > wrote:
> > > > > > >
> > > > > > > On Thu, Jul 11, 2019 at 07:43:16PM +0200, Michael Nazzareno
> > > > > > > Trimarchi wrote:
> > > > > > > > > > tcon-pixel clock is the rate that you want to achive on
> > > > > > > > > > display side
> > > > > > > > > > and if you have 4 lanes 32bit or lanes and different bit
> > > > > > > > > > number that
> > > > > > > > > > you need to have a clock that is able to put outside bits
> > > > > > > > > > and speed
> > > > > > > > > > equal to pixel-clock * bits / lanes. so If you want a
> > > > > > > > > > pixel-clock of
> > > > > > > > > > 40 mhz and you have 32bits and 4 lanes you need to have a
> > > > > > > > > > clock of
> > > > > > > > > > 40 * 32 / 4 in no-burst mode. I think that this is done but
> > > > > > > > > > most of
> > > > > > > > > > the display.
> > > > > > > > >
> > > > > > > > > So this is what the issue is then?
> > > > > > > > >
> > > > > > > > > This one does make sense, and you should just change the rate
> > > > > > > > > in the
> > > > > > > > > call to clk_set_rate in sun4i_tcon0_mode_set_cpu.
> > > > > > > > >
> > > > > > > > > I'm still wondering why that hasn't been brought up in either
> > > > > > > > > the
> > > > > > > > > discussion or the commit log before though.
> > > > > > > > >
> > > > > > > > Something like this?
> > > > > > > >
> > > > > > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +++-
> > > > > > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 2 --
> > > > > > > > 2 files changed, 11 insertions(+), 11 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > > index 64c43ee6bd92..42560d5c327c 100644
> > > > > > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > > @@ -263,10 +263,11 @@ static int sun4i_tcon_get_clk_delay(const
> > > > > > > > struct
> > > > > > > > drm_display_mode *mode,
> > > > > > > > }
> > > > > > > >
> > > > > > > > static void sun4i_tcon0_mode_set_common(struct sun4i_tcon
> > > > > > > > *tcon,
> > > > > > > > - const struct
> > > > > > > > drm_display_mode *mode)
> > > > > > > > + const struct
> > > > > > > > drm_display_mode *mode,
> > > > > > > > + u32 tcon_mul)
> > > > > > > > {
> > > > > > > > /* Configure the dot clock */
> > > > > > > > - clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
> > > > > > > > + clk_set_rate(tcon->dclk, mode->crtc_clock * tcon_mul *
> > > > > > > > 1000);
> > > > > > > >
> > > > > > > > /* Set the resolution */
> > > > > > > >
[linux-sunxi] Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
Hi Maxime
On Mon, Jul 29, 2019 at 8:59 AM Michael Nazzareno Trimarchi
wrote:
>
> Hi
>
> On Wed, Jul 24, 2019 at 11:05 AM Maxime Ripard
> wrote:
> >
> > On Mon, Jul 22, 2019 at 03:51:04PM +0530, Jagan Teki wrote:
> > > Hi Maxime,
> > >
> > > On Sat, Jul 20, 2019 at 3:02 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Sat, Jul 20, 2019 at 12:46:27PM +0530, Jagan Teki wrote:
> > > > > On Sat, Jul 20, 2019 at 12:28 PM Maxime Ripard
> > > > > wrote:
> > > > > >
> > > > > > On Thu, Jul 11, 2019 at 07:43:16PM +0200, Michael Nazzareno
> > > > > > Trimarchi wrote:
> > > > > > > > > tcon-pixel clock is the rate that you want to achive on
> > > > > > > > > display side
> > > > > > > > > and if you have 4 lanes 32bit or lanes and different bit
> > > > > > > > > number that
> > > > > > > > > you need to have a clock that is able to put outside bits and
> > > > > > > > > speed
> > > > > > > > > equal to pixel-clock * bits / lanes. so If you want a
> > > > > > > > > pixel-clock of
> > > > > > > > > 40 mhz and you have 32bits and 4 lanes you need to have a
> > > > > > > > > clock of
> > > > > > > > > 40 * 32 / 4 in no-burst mode. I think that this is done but
> > > > > > > > > most of
> > > > > > > > > the display.
> > > > > > > >
> > > > > > > > So this is what the issue is then?
> > > > > > > >
> > > > > > > > This one does make sense, and you should just change the rate
> > > > > > > > in the
> > > > > > > > call to clk_set_rate in sun4i_tcon0_mode_set_cpu.
> > > > > > > >
> > > > > > > > I'm still wondering why that hasn't been brought up in either
> > > > > > > > the
> > > > > > > > discussion or the commit log before though.
> > > > > > > >
> > > > > > > Something like this?
> > > > > > >
> > > > > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +++-
> > > > > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 2 --
> > > > > > > 2 files changed, 11 insertions(+), 11 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > index 64c43ee6bd92..42560d5c327c 100644
> > > > > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > @@ -263,10 +263,11 @@ static int sun4i_tcon_get_clk_delay(const
> > > > > > > struct
> > > > > > > drm_display_mode *mode,
> > > > > > > }
> > > > > > >
> > > > > > > static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon,
> > > > > > > - const struct
> > > > > > > drm_display_mode *mode)
> > > > > > > + const struct
> > > > > > > drm_display_mode *mode,
> > > > > > > + u32 tcon_mul)
> > > > > > > {
> > > > > > > /* Configure the dot clock */
> > > > > > > - clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
> > > > > > > + clk_set_rate(tcon->dclk, mode->crtc_clock * tcon_mul *
> > > > > > > 1000);
> > > > > > >
> > > > > > > /* Set the resolution */
> > > > > > > regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
> > > > > > > @@ -335,12 +336,13 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > > > > > > sun4i_tcon *tcon,
> > > > > > > u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
> > > > > > > u8 lanes = device->lanes;
> > > > > > > u32 block_space, start_delay;
> > > > > >
[linux-sunxi] Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
Hi
On Wed, Jul 24, 2019 at 11:05 AM Maxime Ripard
wrote:
>
> On Mon, Jul 22, 2019 at 03:51:04PM +0530, Jagan Teki wrote:
> > Hi Maxime,
> >
> > On Sat, Jul 20, 2019 at 3:02 PM Maxime Ripard
> > wrote:
> > >
> > > On Sat, Jul 20, 2019 at 12:46:27PM +0530, Jagan Teki wrote:
> > > > On Sat, Jul 20, 2019 at 12:28 PM Maxime Ripard
> > > > wrote:
> > > > >
> > > > > On Thu, Jul 11, 2019 at 07:43:16PM +0200, Michael Nazzareno Trimarchi
> > > > > wrote:
> > > > > > > > tcon-pixel clock is the rate that you want to achive on display
> > > > > > > > side
> > > > > > > > and if you have 4 lanes 32bit or lanes and different bit number
> > > > > > > > that
> > > > > > > > you need to have a clock that is able to put outside bits and
> > > > > > > > speed
> > > > > > > > equal to pixel-clock * bits / lanes. so If you want a
> > > > > > > > pixel-clock of
> > > > > > > > 40 mhz and you have 32bits and 4 lanes you need to have a clock
> > > > > > > > of
> > > > > > > > 40 * 32 / 4 in no-burst mode. I think that this is done but
> > > > > > > > most of
> > > > > > > > the display.
> > > > > > >
> > > > > > > So this is what the issue is then?
> > > > > > >
> > > > > > > This one does make sense, and you should just change the rate in
> > > > > > > the
> > > > > > > call to clk_set_rate in sun4i_tcon0_mode_set_cpu.
> > > > > > >
> > > > > > > I'm still wondering why that hasn't been brought up in either the
> > > > > > > discussion or the commit log before though.
> > > > > > >
> > > > > > Something like this?
> > > > > >
> > > > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +++-
> > > > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 2 --
> > > > > > 2 files changed, 11 insertions(+), 11 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > index 64c43ee6bd92..42560d5c327c 100644
> > > > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > @@ -263,10 +263,11 @@ static int sun4i_tcon_get_clk_delay(const
> > > > > > struct
> > > > > > drm_display_mode *mode,
> > > > > > }
> > > > > >
> > > > > > static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon,
> > > > > > - const struct
> > > > > > drm_display_mode *mode)
> > > > > > + const struct
> > > > > > drm_display_mode *mode,
> > > > > > + u32 tcon_mul)
> > > > > > {
> > > > > > /* Configure the dot clock */
> > > > > > - clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
> > > > > > + clk_set_rate(tcon->dclk, mode->crtc_clock * tcon_mul *
> > > > > > 1000);
> > > > > >
> > > > > > /* Set the resolution */
> > > > > > regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
> > > > > > @@ -335,12 +336,13 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > > > > > sun4i_tcon *tcon,
> > > > > > u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
> > > > > > u8 lanes = device->lanes;
> > > > > > u32 block_space, start_delay;
> > > > > > - u32 tcon_div;
> > > > > > + u32 tcon_div, tcon_mul;
> > > > > >
> > > > > > - tcon->dclk_min_div = SUN6I_DSI_TCON_DIV;
> > > > > > - tcon->dclk_max_div = SUN6I_DSI_TCON_DIV;
> > > > > > + tcon->dclk_min_div = 4;
> > > > > > + tcon->dclk_max_div = 127;
> > > > > >
> > > > > > -
[linux-sunxi] Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
Hi Jagan
On Mon, Jul 22, 2019 at 12:21 PM Jagan Teki wrote:
>
> Hi Maxime,
>
> On Sat, Jul 20, 2019 at 3:02 PM Maxime Ripard
> wrote:
> >
> > On Sat, Jul 20, 2019 at 12:46:27PM +0530, Jagan Teki wrote:
> > > On Sat, Jul 20, 2019 at 12:28 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Thu, Jul 11, 2019 at 07:43:16PM +0200, Michael Nazzareno Trimarchi
> > > > wrote:
> > > > > > > tcon-pixel clock is the rate that you want to achive on display
> > > > > > > side
> > > > > > > and if you have 4 lanes 32bit or lanes and different bit number
> > > > > > > that
> > > > > > > you need to have a clock that is able to put outside bits and
> > > > > > > speed
> > > > > > > equal to pixel-clock * bits / lanes. so If you want a pixel-clock
> > > > > > > of
> > > > > > > 40 mhz and you have 32bits and 4 lanes you need to have a clock of
> > > > > > > 40 * 32 / 4 in no-burst mode. I think that this is done but most
> > > > > > > of
> > > > > > > the display.
> > > > > >
> > > > > > So this is what the issue is then?
> > > > > >
> > > > > > This one does make sense, and you should just change the rate in the
> > > > > > call to clk_set_rate in sun4i_tcon0_mode_set_cpu.
> > > > > >
> > > > > > I'm still wondering why that hasn't been brought up in either the
> > > > > > discussion or the commit log before though.
> > > > > >
> > > > > Something like this?
> > > > >
> > > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +++-
> > > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 2 --
> > > > > 2 files changed, 11 insertions(+), 11 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > index 64c43ee6bd92..42560d5c327c 100644
> > > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > @@ -263,10 +263,11 @@ static int sun4i_tcon_get_clk_delay(const struct
> > > > > drm_display_mode *mode,
> > > > > }
> > > > >
> > > > > static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon,
> > > > > - const struct drm_display_mode
> > > > > *mode)
> > > > > + const struct drm_display_mode
> > > > > *mode,
> > > > > + u32 tcon_mul)
> > > > > {
> > > > > /* Configure the dot clock */
> > > > > - clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
> > > > > + clk_set_rate(tcon->dclk, mode->crtc_clock * tcon_mul * 1000);
> > > > >
> > > > > /* Set the resolution */
> > > > > regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
> > > > > @@ -335,12 +336,13 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > > > > sun4i_tcon *tcon,
> > > > > u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
> > > > > u8 lanes = device->lanes;
> > > > > u32 block_space, start_delay;
> > > > > - u32 tcon_div;
> > > > > + u32 tcon_div, tcon_mul;
> > > > >
> > > > > - tcon->dclk_min_div = SUN6I_DSI_TCON_DIV;
> > > > > - tcon->dclk_max_div = SUN6I_DSI_TCON_DIV;
> > > > > + tcon->dclk_min_div = 4;
> > > > > + tcon->dclk_max_div = 127;
> > > > >
> > > > > - sun4i_tcon0_mode_set_common(tcon, mode);
> > > > > + tcon_mul = bpp / lanes;
> > > > > + sun4i_tcon0_mode_set_common(tcon, mode, tcon_mul);
> > > > >
> > > > > /* Set dithering if needed */
> > > > > sun4i_tcon0_mode_set_dithering(tcon,
> > > > > sun4i_tcon_get_connector(encoder));
> > > > > @@ -366,7 +368,7 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > > > > sun4i_tcon *tcon,
> > > > > */
> > &
[linux-sunxi] Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
Hi
On Sat, Jul 20, 2019 at 11:32 AM Maxime Ripard
wrote:
>
> On Sat, Jul 20, 2019 at 12:46:27PM +0530, Jagan Teki wrote:
> > On Sat, Jul 20, 2019 at 12:28 PM Maxime Ripard
> > wrote:
> > >
> > > On Thu, Jul 11, 2019 at 07:43:16PM +0200, Michael Nazzareno Trimarchi
> > > wrote:
> > > > > > tcon-pixel clock is the rate that you want to achive on display side
> > > > > > and if you have 4 lanes 32bit or lanes and different bit number that
> > > > > > you need to have a clock that is able to put outside bits and speed
> > > > > > equal to pixel-clock * bits / lanes. so If you want a pixel-clock of
> > > > > > 40 mhz and you have 32bits and 4 lanes you need to have a clock of
> > > > > > 40 * 32 / 4 in no-burst mode. I think that this is done but most of
> > > > > > the display.
> > > > >
> > > > > So this is what the issue is then?
> > > > >
> > > > > This one does make sense, and you should just change the rate in the
> > > > > call to clk_set_rate in sun4i_tcon0_mode_set_cpu.
> > > > >
> > > > > I'm still wondering why that hasn't been brought up in either the
> > > > > discussion or the commit log before though.
> > > > >
> > > > Something like this?
> > > >
> > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +++-
> > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 2 --
> > > > 2 files changed, 11 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > index 64c43ee6bd92..42560d5c327c 100644
> > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > @@ -263,10 +263,11 @@ static int sun4i_tcon_get_clk_delay(const struct
> > > > drm_display_mode *mode,
> > > > }
> > > >
> > > > static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon,
> > > > - const struct drm_display_mode
> > > > *mode)
> > > > + const struct drm_display_mode
> > > > *mode,
> > > > + u32 tcon_mul)
> > > > {
> > > > /* Configure the dot clock */
> > > > - clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
> > > > + clk_set_rate(tcon->dclk, mode->crtc_clock * tcon_mul * 1000);
> > > >
> > > > /* Set the resolution */
> > > > regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
> > > > @@ -335,12 +336,13 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > > > sun4i_tcon *tcon,
> > > > u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
> > > > u8 lanes = device->lanes;
> > > > u32 block_space, start_delay;
> > > > - u32 tcon_div;
> > > > + u32 tcon_div, tcon_mul;
> > > >
> > > > - tcon->dclk_min_div = SUN6I_DSI_TCON_DIV;
> > > > - tcon->dclk_max_div = SUN6I_DSI_TCON_DIV;
> > > > + tcon->dclk_min_div = 4;
> > > > + tcon->dclk_max_div = 127;
> > > >
> > > > - sun4i_tcon0_mode_set_common(tcon, mode);
> > > > + tcon_mul = bpp / lanes;
> > > > + sun4i_tcon0_mode_set_common(tcon, mode, tcon_mul);
> > > >
> > > > /* Set dithering if needed */
> > > > sun4i_tcon0_mode_set_dithering(tcon,
> > > > sun4i_tcon_get_connector(encoder));
> > > > @@ -366,7 +368,7 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > > > sun4i_tcon *tcon,
> > > > */
> > > > regmap_read(tcon->regs, SUN4I_TCON0_DCLK_REG, &tcon_div);
> > > > tcon_div &= GENMASK(6, 0);
> > > > - block_space = mode->htotal * bpp / (tcon_div * lanes);
> > > > + block_space = mode->htotal * tcon_div * tcon_mul;
> > > > block_space -= mode->hdisplay + 40;
> > > >
> > > > regmap_write(tcon->regs, SUN4I_TCON0_CPU_TRI0_REG,
> > > > @@ -408,7 +410,7 @@ static void sun4i_tcon0_mode_set_lvds(struct
> > > > sun4i_tcon *tcon,
> > > >
> > > >
[linux-sunxi] Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
Hi
On Sat., 20 Jul. 2019, 8:58 am Maxime Ripard,
wrote:
> On Thu, Jul 11, 2019 at 07:43:16PM +0200, Michael Nazzareno Trimarchi
> wrote:
> > > > tcon-pixel clock is the rate that you want to achive on display side
> > > > and if you have 4 lanes 32bit or lanes and different bit number that
> > > > you need to have a clock that is able to put outside bits and speed
> > > > equal to pixel-clock * bits / lanes. so If you want a pixel-clock of
> > > > 40 mhz and you have 32bits and 4 lanes you need to have a clock of
> > > > 40 * 32 / 4 in no-burst mode. I think that this is done but most of
> > > > the display.
> > >
> > > So this is what the issue is then?
> > >
> > > This one does make sense, and you should just change the rate in the
> > > call to clk_set_rate in sun4i_tcon0_mode_set_cpu.
> > >
> > > I'm still wondering why that hasn't been brought up in either the
> > > discussion or the commit log before though.
> > >
> > Something like this?
> >
> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +++-
> > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 2 --
> > 2 files changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > index 64c43ee6bd92..42560d5c327c 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > @@ -263,10 +263,11 @@ static int sun4i_tcon_get_clk_delay(const struct
> > drm_display_mode *mode,
> > }
> >
> > static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon,
> > - const struct drm_display_mode
> *mode)
> > + const struct drm_display_mode
> *mode,
> > + u32 tcon_mul)
> > {
> > /* Configure the dot clock */
> > - clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
> > + clk_set_rate(tcon->dclk, mode->crtc_clock * tcon_mul * 1000);
> >
> > /* Set the resolution */
> > regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
> > @@ -335,12 +336,13 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > sun4i_tcon *tcon,
> > u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
> > u8 lanes = device->lanes;
> > u32 block_space, start_delay;
> > - u32 tcon_div;
> > + u32 tcon_div, tcon_mul;
> >
> > - tcon->dclk_min_div = SUN6I_DSI_TCON_DIV;
> > - tcon->dclk_max_div = SUN6I_DSI_TCON_DIV;
> > + tcon->dclk_min_div = 4;
> > + tcon->dclk_max_div = 127;
> >
> > - sun4i_tcon0_mode_set_common(tcon, mode);
> > + tcon_mul = bpp / lanes;
> > + sun4i_tcon0_mode_set_common(tcon, mode, tcon_mul);
> >
> > /* Set dithering if needed */
> > sun4i_tcon0_mode_set_dithering(tcon,
> sun4i_tcon_get_connector(encoder));
> > @@ -366,7 +368,7 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > sun4i_tcon *tcon,
> > */
> > regmap_read(tcon->regs, SUN4I_TCON0_DCLK_REG, &tcon_div);
> > tcon_div &= GENMASK(6, 0);
> > - block_space = mode->htotal * bpp / (tcon_div * lanes);
> > + block_space = mode->htotal * tcon_div * tcon_mul;
> > block_space -= mode->hdisplay + 40;
> >
> > regmap_write(tcon->regs, SUN4I_TCON0_CPU_TRI0_REG,
> > @@ -408,7 +410,7 @@ static void sun4i_tcon0_mode_set_lvds(struct
> > sun4i_tcon *tcon,
> >
> > tcon->dclk_min_div = 7;
> > tcon->dclk_max_div = 7;
> > - sun4i_tcon0_mode_set_common(tcon, mode);
> > + sun4i_tcon0_mode_set_common(tcon, mode, 1);
> >
> > /* Set dithering if needed */
> > sun4i_tcon0_mode_set_dithering(tcon,
> sun4i_tcon_get_connector(encoder));
> > @@ -487,7 +489,7 @@ static void sun4i_tcon0_mode_set_rgb(struct
> > sun4i_tcon *tcon,
> >
> > tcon->dclk_min_div = 6;
> > tcon->dclk_max_div = 127;
> > - sun4i_tcon0_mode_set_common(tcon, mode);
> > + sun4i_tcon0_mode_set_common(tcon, mode, 1);
> >
> > /* Set dithering if needed */
> > sun4i_tcon0_mode_set_dithering(tcon, connector);
> > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> > index 5c3ad5be0690..a07090579f84 100644
> > --- a/drivers
[linux-sunxi] Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
Hi On Thu, Jul 11, 2019 at 7:43 PM Michael Nazzareno Trimarchi wrote: > > Hi Maxime > > On Thu, Jul 11, 2019 at 2:23 PM Maxime Ripard > wrote: > > > > On Fri, Jul 05, 2019 at 07:52:27PM +0200, Michael Nazzareno Trimarchi wrote: > > > On Wed, Jul 3, 2019 at 1:49 PM Maxime Ripard > > > wrote: > > > > > > > > On Tue, Jun 25, 2019 at 09:00:36PM +0530, Jagan Teki wrote: > > > > > On Tue, Jun 25, 2019 at 8:19 PM Maxime Ripard > > > > > wrote: > > > > > > > > > > > > On Thu, Jun 20, 2019 at 11:57:44PM +0530, Jagan Teki wrote: > > > > > > > On Fri, Jun 14, 2019 at 7:54 PM Maxime Ripard > > > > > > > wrote: > > > > > > > > > > > > > > > > On Wed, Jun 05, 2019 at 01:03:16PM +0530, Jagan Teki wrote: > > > > > > > > > On Wed, Jun 5, 2019 at 12:19 PM Maxime Ripard > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > I've reordered the mail a bit to work on chunks > > > > > > > > > > > > > > > > > > > > On Fri, May 24, 2019 at 03:37:42PM +0530, Jagan Teki wrote: > > > > > > > > > > > > I wish it was in your commit log in the first place, > > > > > > > > > > > > instead of having > > > > > > > > > > > > to exchange multiple mails over this. > > > > > > > > > > > > > > > > > > > > > > > > However, I don't think that's quite true, and it might > > > > > > > > > > > > be a bug in > > > > > > > > > > > > Allwinner's implementation (or rather something quite > > > > > > > > > > > > confusing). > > > > > > > > > > > > > > > > > > > > > > > > You're right that the lcd_rate and pll_rate seem to be > > > > > > > > > > > > generated from > > > > > > > > > > > > the pixel clock, and it indeed looks like the ratio > > > > > > > > > > > > between the pixel > > > > > > > > > > > > clock and the TCON dotclock is defined through the > > > > > > > > > > > > number of bits per > > > > > > > > > > > > lanes. > > > > > > > > > > > > > > > > > > > > > > > > However, in this case, dsi_rate is actually the same > > > > > > > > > > > > than lcd_rate, > > > > > > > > > > > > since pll_rate is going to be divided by dsi_div: > > > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L791 > > > > > > > > > > > > > > > > > > > > > > > > Since lcd_div is 1, it also means that in this case, > > > > > > > > > > > > dsi_rate == > > > > > > > > > > > > dclk_rate. > > > > > > > > > > > > > > > > > > > > > > > > The DSI module clock however, is always set to 148.5 > > > > > > > > > > > > MHz. Indeed, if > > > > > > > > > > > > we look at: > > > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L804 > > > > > > > > > > > > > > > > > > > > > > > > We can see that the rate in clk_info is used if it's > > > > > > > > > > > > different than > > > > > > > > > > > > 0. This is filled by disp_al_lcd_get_clk_info, which, > > > > > > > > > > > > in the case of a > > > > > > > > > > > > DSI panel, will hardcode it to 148.5 MHz: > > > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/d
[linux-sunxi] Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
Hi Maxime On Thu, Jul 11, 2019 at 2:23 PM Maxime Ripard wrote: > > On Fri, Jul 05, 2019 at 07:52:27PM +0200, Michael Nazzareno Trimarchi wrote: > > On Wed, Jul 3, 2019 at 1:49 PM Maxime Ripard > > wrote: > > > > > > On Tue, Jun 25, 2019 at 09:00:36PM +0530, Jagan Teki wrote: > > > > On Tue, Jun 25, 2019 at 8:19 PM Maxime Ripard > > > > wrote: > > > > > > > > > > On Thu, Jun 20, 2019 at 11:57:44PM +0530, Jagan Teki wrote: > > > > > > On Fri, Jun 14, 2019 at 7:54 PM Maxime Ripard > > > > > > wrote: > > > > > > > > > > > > > > On Wed, Jun 05, 2019 at 01:03:16PM +0530, Jagan Teki wrote: > > > > > > > > On Wed, Jun 5, 2019 at 12:19 PM Maxime Ripard > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I've reordered the mail a bit to work on chunks > > > > > > > > > > > > > > > > > > On Fri, May 24, 2019 at 03:37:42PM +0530, Jagan Teki wrote: > > > > > > > > > > > I wish it was in your commit log in the first place, > > > > > > > > > > > instead of having > > > > > > > > > > > to exchange multiple mails over this. > > > > > > > > > > > > > > > > > > > > > > However, I don't think that's quite true, and it might be > > > > > > > > > > > a bug in > > > > > > > > > > > Allwinner's implementation (or rather something quite > > > > > > > > > > > confusing). > > > > > > > > > > > > > > > > > > > > > > You're right that the lcd_rate and pll_rate seem to be > > > > > > > > > > > generated from > > > > > > > > > > > the pixel clock, and it indeed looks like the ratio > > > > > > > > > > > between the pixel > > > > > > > > > > > clock and the TCON dotclock is defined through the number > > > > > > > > > > > of bits per > > > > > > > > > > > lanes. > > > > > > > > > > > > > > > > > > > > > > However, in this case, dsi_rate is actually the same than > > > > > > > > > > > lcd_rate, > > > > > > > > > > > since pll_rate is going to be divided by dsi_div: > > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L791 > > > > > > > > > > > > > > > > > > > > > > Since lcd_div is 1, it also means that in this case, > > > > > > > > > > > dsi_rate == > > > > > > > > > > > dclk_rate. > > > > > > > > > > > > > > > > > > > > > > The DSI module clock however, is always set to 148.5 MHz. > > > > > > > > > > > Indeed, if > > > > > > > > > > > we look at: > > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L804 > > > > > > > > > > > > > > > > > > > > > > We can see that the rate in clk_info is used if it's > > > > > > > > > > > different than > > > > > > > > > > > 0. This is filled by disp_al_lcd_get_clk_info, which, in > > > > > > > > > > > the case of a > > > > > > > > > > > DSI panel, will hardcode it to 148.5 MHz: > > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L164 > > > > > > > > > > > > > > > > > > > > Let me explain, something more. > > > > > > > > > > > > > > > > > > > > According to bsp there are clk_info.tcon_div which I will > > > > > > > > > > ex
[linux-sunxi] Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
0 > > > > [1.920572] sun4i_dclk_recalc_rate: val = 1, rate = 17820 > > > > [1.920576] sun4i_dclk_recalc_rate: val = 1, rate = 17820 > > > > [1.920597] rate = 17820 > > > > [1.920599] parent_rate = 29700 > > > > [1.920602] reg = 0x90c0 > > > > [1.920605] _nkm.n = 3, nkm->n.offset = 0x1, nkm->n.shift = 8 > > > > [1.920609] _nkm.k = 2, nkm->k.offset = 0x1, nkm->k.shift = 4 > > > > [1.920612] _nkm.m = 10, nkm->m.offset = 0x1, nkm->m.shift = 0 > > > > [1.920958] sun4i_dclk_set_rate div 6 > > > > [1.920966] sun4i_dclk_recalc_rate: val = 6, rate = 2970 > > > > > > > > and clk_summary: > > > > > > > > pll-video0111 29700 > > > > 0 0 5 > > > >hdmi 000 29700 > > > > 0 0 5 > > > >tcon1 000 29700 > > > > 0 0 5 > > > >pll-mipi 111 17820 > > > > 0 0 5 > > > > tcon0 221 17820 > > > > 0 0 5 > > > > tcon-pixel-clock 1112970 > > > > 0 0 5 > > > >pll-video0-2x 000 59400 > > > > 0 0 5 > > > > > > This discussion is going nowhere. I'm telling you that your patch > > > doesn't apply the divider you want on the proper clock, and you're > > > replying that indeed, you're applying it on the wrong clock. > > > > > > It might work by accident in your case, but the board I have here > > > clearly indicates otherwise, so there's two possible way out here: > > > > > > - Either you apply that divider to the TCON *module* clock, and not > > > the dclk > > > > > > - Or you point to somewhere in the allwinner code where the bpp / > > > lanes divider is used for the dclk divider. > > > > I don't know how to proceed further on this, as you say it might work > > in accident but I have tested this in A33, A64 and R40 with 4 > > different DSI panels and one DSI-RGB bridge. All of them do use > > PLL_MIPI (pll_rate) and it indeed depends on bpp/lanes > > > > 4-lane, 24-bit: Novatek NT35596 panel > > 4-lane, 24-bit: Feiyang, FY07024di26a30d panel > > 4-lane, 24-bit: Bananapi-s070wv20 panel > > 2-lane, 24-bit: Techstar,ts8550b panel > > > > and > > > > 4-lane, 24-bit, ICN6211 DSI-to-RGB bridge panel > > > > All above listed panels and bridges are working as per BSP and do > > follow bpp/lanes and for DIVIDER 4 no panel is working. > > Look. I'm not saying that there's no issue, I'm saying that your > patch, applied to the clock you're applying it to, doesn't make sense > and isn't what the BSP does. tcon-pixel clock is the rate that you want to achive on display side and if you have 4 lanes 32bit or lanes and different bit number that you need to have a clock that is able to put outside bits and speed equal to pixel-clock * bits / lanes. so If you want a pixel-clock of 40 mhz and you have 32bits and 4 lanes you need to have a clock of 40 * 32 / 4 in no-burst mode. I think that this is done but most of the display. Now in burst mode I don't know how should work the calculation of the clock for the require bandwidth and even I understand your comment I would like to have your clock tree after you boot on the display side and if it is possible I want to assemble a kit like you have. > > You can keep on arguing that your patch is perfect as is, but the fact > that there's regressions proves otherwise. > Well when you push your code you said that you have tested on more then one display. Can I know where are the others? > > The panels/bridges I have has tested in BSP and as you mentioned in > > another mail, your panel is not tested in BSP - this is the only > > difference. I did much reverse-engineering on PLL_MIPI clocking in BSP > > so I'm afraid what can I do next on this, If you want to look further > > on BSP I would suggest to verify on pll_rate side. If you feel > > anything I'm missing please let me know. > > I already told you how we can make some progress in the mail you > quoted, but you chose to ignore that. > Yes, the idea is to make progress. Thank you about your helping Michael > Until there's been some progress on either points mentionned above, > I'm just going to stop answering on this topic. > > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CAOf5uw%3DZEvMV1hFQE986rNG_ctpReGbjbZzv0m%3DOzKPdBh57uQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] arm64: dts: allwinner: a64-oceanic-5205-5inmfd: Enable CAN
Hi Maxime
On Tue, May 21, 2019 at 10:10 AM Maxime Ripard
wrote:
>
> On Tue, May 21, 2019 at 08:47:02AM +0200, Michael Nazzareno Trimarchi wrote:
> > > > + };
> > > > +
> > > > };
> > > >
> > > > &ehci0 {
> > > > @@ -77,6 +95,31 @@
> > > > status = "okay";
> > > > };
> > > >
> > > > +&pio {
> > > > + can_pins: can-pins {
> > > > + pins = "PD6", /* RX_BUF1_CAN0 */
> > > > +"PD7"; /* RX_BUF0_CAN0 */
> > > > + function = "gpio_in";
> > > > + };
> > > > +};
> > >
> > > That isn't needed. What are they used for, you're not tying them to
> > > anything?
> >
> > Mux of their function is correct. They are connected in the schematics
> > but not used right now.
>
> Then describe the whole thing or don't?
>
Ok
> And that's kind of missing my point. If that pin group isn't related
> to any device, the pin muxing will not be changed. So that group, in
> itself, has strictly no effect.
>
> Moreover, you don't need a pin group in the first place to mux pins in
> GPIOs, the GPIO API will make sure that is the case when you request
> it.
This is correct on sunxi. Is this valid for sunxi or in general in all the SoC?
Anyway make sense to have pins configured and place in the right
state, just suppose if the
booting stage is wrong or anything that make those pins in the wrong
configuration
>
> > I can garantee that kernel wlll always configurred in the right way
> > and if I want I can export in userspace
> > for debug purpose
Correct if you start to use it but if you want them right configured
the right place
is in the default state e/o initstate if this can be a problem of the hardware
Default state: the state the pinctrl handle shall be put
* into as default, usually this means the pins are up and ready to
* be used by the device driver. This state is commonly used by
* hogs to configure muxing and pins at boot, and also as a state
* to go into when returning from sleep and idle in
* .pm_runtime_resume() or ordinary .resume() for example.
Now the pins are connected to the canbus as should be and they are
configured and usually
put in the right state.
+ compatible = "microchip,mcp2515";
+ reg = <0>;
+ spi-max-frequency = <1000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&can_pins>;
>
> Yes, because the API does it, not your change
>
Do you prefer to drop the pinmux? or update the commit message
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/CAOf5uwnhXjur%3D2NezCydaCxP5d33S%2BAwdD9WTDtp2EUJr4UTgg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] arm64: dts: allwinner: a64-oceanic-5205-5inmfd: Enable CAN
Hi Maxime
On Thu, Apr 18, 2019 at 4:56 PM Maxime Ripard wrote:
>
> On Thu, Apr 18, 2019 at 07:46:58PM +0530, Jagan Teki wrote:
> > Oceanic 5205 5inMFD has MCP2515 CAN device connected via SPI1.
> >
> > - via SPI1 bus
> > - vdd supplied by 5V supply along with PL2 enable pin
> > - xceiver supply same as vdd
> > - can oscillator connected at 20MHz
> > - PB2 gpio as interrupt pin
> > - PD6 gpio as RX_BUF1_CAN0
> > - PD7 gpio as RX_BUF0_CAN0
> >
> > Tested-by: Tamas Papp
> > Signed-off-by: Jagan Teki
> > ---
> > .../sun50i-a64-oceanic-5205-5inmfd.dts| 43 +++
> > 1 file changed, 43 insertions(+)
> >
> > diff --git
> > a/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts
> > index f0cd6587f619..22535a297f51 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts
> > @@ -21,6 +21,24 @@
> > chosen {
> > stdout-path = "serial0:115200n8";
> > };
> > +
> > + can_osc: can-osc {
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <2000>;
> > + };
> > +
> > + reg_can_v5v: reg-can-v5v {
> > + compatible = "regulator-fixed";
> > + regulator-name = "reg-can-v5v";
> > + regulator-min-microvolt = <500>;
> > + regulator-max-microvolt = <500>;
> > + regulator-boot-on;
> > + enable-active-high;
> > + gpio = <&r_pio 0 2 GPIO_ACTIVE_HIGH>; /* CAN_3V3_EN: PL2 */
> > + status = "okay";
>
> You don't need the status property here.
>
Correct, need to be dropped
> > + };
> > +
> > };
> >
> > &ehci0 {
> > @@ -77,6 +95,31 @@
> > status = "okay";
> > };
> >
> > +&pio {
> > + can_pins: can-pins {
> > + pins = "PD6", /* RX_BUF1_CAN0 */
> > +"PD7"; /* RX_BUF0_CAN0 */
> > + function = "gpio_in";
> > + };
> > +};
>
> That isn't needed. What are they used for, you're not tying them to
> anything?
Mux of their function is correct. They are connected in the schematics
but not used right now.
I can garantee that kernel wlll always configurred in the right way
and if I want I can export in userspace
for debug purpose
Michael
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/CAOf5uwn8CtRs8cx0KC-bxNoRP4TiDrHi8F83QfjsZhueLDYFJg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [U-Boot] SPL variant of sunxi nand module
Hi On Sun, Dec 23, 2018 at 4:46 PM Nikolai Zhubr wrote: > > Hi again, > > 23.12.2018 16:29, I wrote: > > > U-Boot SPL 2019.01-rc2 (Dec 20 2018 - 16:30:46 +0300) > > > CPU: 91200Hz, AXI/AHB/APB: 3/2/2 > > > DRAM: 1024 MiB > > > Trying to boot from NAND > > > > Ok, discovered a special SPL-only sunxi_nand_spl variant, added some > debugging, so the detection is visible: > > In nand_detect_config(), start detection... > Considering addr_cycles=5, page_size=2048 > Considering ecc_size=1024, ecc_strength=0 failed(a). > Considering addr_cycles=5, page_size=2048 rejected. > Considering addr_cycles=5, page_size=4096 > Considering ecc_size=1024, ecc_strength=3 failed(a). > Considering addr_cycles=5, page_size=4096 rejected. > Considering addr_cycles=5, page_size=8192 > Considering ecc_size=1024, ecc_strength=4 good(b). > Considering addr_cycles=5, page_size=8192 accepted. > > I'm almost 100% sure that correct config would be page_size=8192, > ecc_size=1024, ecc_strength=40 (from nand chip identification structure > for regular linux kernel) That is an index on an array. Am I wrong? so the max is 74 Michael > > Now the detection routine in sunxi_nand_spl apparently comes up with a > value of ecc_strength=4 instead... Why is that? n - 1 using an index, if the code that I have is aligned so Michael > > > Thank you, > > Regards, > Nikolai > > > > > > > > Thank you, > > > > Regards, > > Nikolai > > ___ > > U-Boot mailing list > > u-b...@lists.denx.de > > https://lists.denx.de/listinfo/u-boot > > ___ > U-Boot mailing list > u-b...@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v4 0/6] media/sun6i: Allwinner A64 CSI support
Hi Maxime On Wed, Dec 19, 2018 at 11:25 AM Maxime Ripard wrote: > > On Tue, Dec 18, 2018 at 08:58:22PM +0530, Jagan Teki wrote: > > On Tue, Dec 18, 2018 at 8:51 PM Maxime Ripard > > wrote: > > > > > > On Tue, Dec 18, 2018 at 05:03:14PM +0530, Jagan Teki wrote: > > > > This series support CSI on Allwinner A64. > > > > > > > > Tested 640x480, 320x240, 720p, 1080p resolutions UYVY8_2X8 format. > > > > > > > > Changes for v4: > > > > - update the compatible string order > > > > - add proper commit message > > > > - included BPI-M64 patch > > > > - skipped amarula-a64 patch > > > > Changes for v3: > > > > - update dt-bindings for A64 > > > > - set mod clock via csi driver > > > > - remove assign clocks from dtsi > > > > - remove i2c-gpio opendrian > > > > - fix avdd and dovdd supplies > > > > - remove vcc-csi pin group supply > > > > > > > > Note: This series created on top of H3 changes [1] > > > > > > > > [1] https://patchwork.kernel.org/cover/10705905/ > > > > > > You had memory corruption before, how was this fixed? > > > > Memory corruption observed with default 600MHz on 1080p. It worked > > fine on BPI-M64 (with 300MHz) > > I don't get it. In the previous version of those patches, you were > mentionning you were still having this issue, even though you had the > clock running at 300MHz, and then you tried to convince us to merge > the patches nonetheless. > > Why would you say that then if that issue was fixed? It's simple, we have a full working platform with ov5640 that support all the resolutions, that can be test by anyone and we have an industrial product that has some problem on high xvclk because it can not give us a clear image but this is limited on another design and another camera module vendor. Problem is not in the kernel code but it's just on relic design. We are getting the information on that module and see if inside is really using the xvclk or it's clocked by some other things. We have only the schematic up to the connector. Michael > > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [U-Boot] [linux-sunxi] [PATCH] Revert "sunxi: board: Print error after power initialization fails"
Hi André On Wed, Dec 19, 2018 at 2:46 AM André Przywara wrote: > > On 19/12/2018 00:51, André Przywara wrote: > > On 18/12/2018 12:06, Jagan Teki wrote: > >> On Tue, Dec 18, 2018 at 4:09 PM wrote: > >>> > >>> From: Karl Palsson > >>> > >>> This reverts commit a8011eb84dfac5187cebf00ed8bc981bdb5c1fa1 > >>> > >>> This causes DRAM init failures on (at least) > >>> * allwinner h3 nanopi-duo2 > >>> * allwinner h2+ orangepi zero v1.1 > >>> > >>> Signed-off-by: Karl Palsson > >>> --- > >>> > >>> Ideally, this should get into 2019.01, so that this release is not > >>> broken on those targets. > >> > >> Better to understand the issue here, since I have BPI-M2+ which boots > >> fine w/o this revert. > > > > Could this be a .bss issue? This lies in DRAM and is thus only available > > *after* DRAM init. IIRC we silently rely on not accessing anything in > > .bss before the DRAM is up, see 59d07ee08e85 for instance. > > I don't immediately spot any .bss usage in clock_set_pll1(), though. > > > > Or is the 1GHz CPU clock speed too fast for the DRAM init? If I am not > > mistaken, we run with 24MHz before, so there might be some "natural" > > delay in some setup routines. Some DRAM chips or board layout might be > > more susceptible to this than others, which might explain why it only > > fails on some boards. > > Just did some testing on my OrangePi Zero: if I force the CPU frequency > to 408 MHz, it works, but fails with the standard 1008 MHz. > So this smells that we indeed miss some delays in the DRAM setup code, > which sounds tedious to find. There are a number of delays, but those > are fine as they are timer controlled, so independent from the CPU > frequency. > > For now I think that reverting would be the easiest solution. Somewhat > in contrast to what the commit message says, we don't really change > anything in terms of error *checking*, as the code carries on anyways > (just without increasing the CPU frequency). The only real difference is > the order of CPU clock setup and DRAM init. > > Karl, can you please amend the commit message to mention the CPU > frequency issue? > > > So if the original patch is about bailing out on error early, can't we > > just do *that* before the DRAM init, keeping the CPU clock setup still > > after DRAM? > > Just checked, this works as well, but is a bit pointless. Just reverting > this and meanwhile checking the DRAM init code seems the easier solution. > Definitely have the same impression. Please send the same revert but adjust the commit message Michael > Cheers, > Andre > ___ > U-Boot mailing list > u-b...@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [U-Boot] [linux-sunxi] [PATCH] Revert "sunxi: board: Print error after power initialization fails"
Hi Karl On Tue, Dec 18, 2018 at 7:12 PM Karl Palsson wrote: > > > Jagan Teki wrote: > > It's 4 days before, "U-Boot] sunxi: regression in dram init for > > h3 board" > > > > 7 days is not 4-days :) > > True, it was last week, not a week ago. > > > I would expect some debugging on this during these days and > > find the real root cause. > > Just so there's no unmet expectations here, I'm not doing any > _debugging_ of this. (Nor do I have any planned) Given that this > is a regression in working devices, I would _presume_ (quite > likely wrongly) that the honus of debugging this would be on the > people who suggested this patch, not people affected by it. I'm > happy to test things, but I have zero experience with dram init, > (only marginally greater than zero experience with uboot overall) > and no sane methods for debugging this further, nor enough > devices to give any test confidence that any debugging I could do > would be useful. > Do you have error after relocation or before relocation? Does it go outside and print DRAM size? Michael > Sincerely, > Karl P_______ > U-Boot mailing list > u-b...@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: Allwinner A64: Issue on external rtc clock to wifi chip
Hi Maxime
On Mon, May 14, 2018 at 1:17 PM, Maxime Ripard
wrote:
> On Mon, May 14, 2018 at 03:12:49PM +0530, Jagan Teki wrote:
>> On Mon, May 14, 2018 at 2:36 PM, Maxime Ripard
>> wrote:
>> > On Mon, May 14, 2018 at 02:34:22PM +0530, Jagan Teki wrote:
>> >> On Mon, May 14, 2018 at 1:57 PM, Maxime Ripard
>> >> wrote:
>> >> > On Mon, May 14, 2018 at 01:34:56PM +0530, Jagan Teki wrote:
>> >> >> On Mon, May 14, 2018 at 1:27 PM, Maxime Ripard
>> >> >> wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > On Mon, May 14, 2018 at 12:37:49PM +0530, Jagan Teki wrote:
>> >> >> >> Hi Maxime and All,
>> >> >> >>
>> >> >> >> We are trying to bring-up AP6330 Wifi chip for A64 board. We noticed
>> >> >> >> to have an external rtc clock has driven from wifi chip.
>> >> >> >>
>> >> >> >> So the devicetree is configured according to this as below.
>> >> >> >>
>> >> >> >> / {
>> >> >> >> wifi_pwrseq: wifi-pwrseq {
>> >> >> >> compatible = "mmc-pwrseq-simple";
>> >> >> >> clocks = <&rtc 1>;
>> >> >> >> clock-names = "ext_clock";
>> >> >> >> reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2
>> >> >> >> */
>> >> >> >> post-power-on-delay-ms = <400>;
>> >> >> >> };
>> >> >> >> };
>> >> >> >>
>> >> >> >> &rtc {
>> >> >> >> clock-output-names = "rtc-osc32k", "rtc-osc32k-out";
>> >> >> >> clocks = <&osc32k>;
>> >> >> >> #clock-cells = <1>;
>> >> >> >> };
>> >> >> >>
>> >> >> >> &mmc1 {
>> >> >> >> pinctrl-names = "default";
>> >> >> >> pinctrl-0 = <&mmc1_pins>;
>> >> >> >> vmmc-supply = <®_dcdc1>;
>> >> >> >> vqmmc-supply = <®_eldo1>;
>> >> >> >> mmc-pwrseq = <&wifi_pwrseq>;
>> >> >> >> bus-width = <4>;
>> >> >> >> non-removable;
>> >> >> >> status = "okay";
>> >> >> >>
>> >> >> >> brcmf: wifi@1 {
>> >> >> >> reg = <1>;
>> >> >> >> compatible = "brcm,bcm4329-fmac";
>> >> >> >> interrupt-parent = <&r_pio>;
>> >> >> >> interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /*
>> >> >> >> WL-WAKE-AP: PL3 */
>> >> >> >> interrupt-names = "host-wake";
>> >> >> >> };
>> >> >> >> };
>> >> >> >>
>> >> >> >> And observed rtc-osc32k-out clock is never enabled[1] and the value
>> >> >> >> of
>> >> >> >> LOSC_OUT_GATING is 0x0 which eventually not enabling
>> >> >> >> LOSC_OUT_GATING_EN
>> >> >> >>
>> >> >> >> Pls. let us know if we miss anything here?
>> >> >> >>
>> >> >> >> [1] https://paste.ubuntu.com/p/X2By4q8kD2/
>> >> >> >
>> >> >> > Could you paste your config and the logs from a boot to?
>> >> >>
>> >> >> .config
>> >> >> https://paste.ubuntu.com/p/w9w2KB7RFc/
>> >> >>
>> >> >> dmesg
>> >> >> https://paste.ubuntu.com/p/mrZGk5bWRR/
>> >> >
>> >> > This is kind of weird. Have you tested with a 4.17 kernel? We have
>> >> > runtime_pm changes lined up in next, so that might be a regression
>> >> > there, even though we tested it with Quentin at some point.
>> >>
>> >> This is 4.17-rc4 do you want to try it on 4.16 ?
>> >
>> > No, this is next-20180503. Please try with 4.17-rc4
>>
>> Couldn't find any different in behaviour [2]
>>
>> [2] https://paste.ubuntu.com/p/m3PGBwrv6W/
>
> It's hard to tell without the board, but have you looked at the return
> value of devm_clk_get in the pwrseq code?
>
> Enabling the clk ftrace events would also help.
>
The driver has one bug.
diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index 2e6fb27..a66f40c 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -74,7 +74,7 @@
#define SUN6I_ALARM_CONFIG_WAKEUP BIT(0)
#define SUN6I_LOSC_OUT_GATING 0x0060
-#define SUN6I_LOSC_OUT_GATING_EN BIT(0)
+#define SUN6I_LOSC_OUT_GATING_EN 0
You need to pass bit_idx that is 0 and not BIT(0)
Michael
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
