From: Andre Przywara <andre.przywara@arm.com>
To: "Jernej Škrabec" <jernej.skrabec@gmail.com>
Cc: jagan@amarulasolutions.com, u-boot@lists.denx.de
Subject: Re: [PATCH 0/8] sunxi: Update H616 DRAM driver
Date: Wed, 4 Jan 2023 23:21:48 +0000 [thread overview]
Message-ID: <20230104232148.5456b4ba@slackpad.lan> (raw)
In-Reply-To: <4767183.GXAFRqVoOG@jernej-laptop>
On Wed, 04 Jan 2023 22:02:33 +0100
Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
Hi Jernej,
> Dne sreda, 04. januar 2023 ob 01:47:16 CET je Andre Przywara napisal(a):
> > On Sun, 11 Dec 2022 17:32:05 +0100
> > Jernej Skrabec <jernej.skrabec@gmail.com> wrote:
> >
> > Hi Jernej,
> >
> > > Current H616 DRAM driver is completely customized to Orange Pi Zero2
> > > board, which is currently the only H616 board supported by U-Boot.
> > > Needless to say, this is not ideal for adding new boards. With changes
> > > in this series, all DDR3 boards are supported and all that is needed is
> > > just vendor DRAM values extracted from Android image. New DRAM types
> > > should also be easier to support, since a lot of constants used before
> > > are not really DRAM type dependent.
> > >
> > > Changes were verified by decompiling driver and generated values were
> > > compared to previous, hard coded ones. This was done without dram_para
> > > structures, so compiler was able to heavily optimize code and produce
> > > constants.
> >
> > so many thanks again for putting this together!
> > I came to like (the idea of) this series very much lately, as this
> > removes timing/delay values from the code, and easily allows putting the
> > vendor provided values in the defconfig.
> > I used that approach as well for the D1 driver, and am wondering if we
> > should extend this to other SoCs, potentially unifying the Kconfig part?
>
> While it would be nice, I'm not sure it's worth the effort and there is a
> chance that something might break during rework.
Fair enough, was just an idea.
> > And you hinted at a v2, can you provide an estimate for this? If you
> > send it still this week, I would like to put it into U-Boot's next
> > branch, otherwise it goes straight into master, should the merge window
> > open next week as planned.
>
> I have changes for v2 in my github repo. I don't have any estimation, since I
> had some time off from programming lately
Sounds good!
> and I'm just only catching up.
> Weekend at earliest, but no promises.
No worries, that was a genuine question, for my planning. I have plenty
of other things to do, and we have still plenty of time (till end of
January or so) to get things merged.
> > Btw., to verify the feasibility of drivers/ram/sunxi, I moved the H616
> > driver into there, together with the Kconfig parts, I wonder what you
> > think about this? An example of how this looks is in the D1 driver
> > patches.
>
> Looks good, but I don't know what are implications regarding interface. Is
> just code move or that implies that some ram framework must be used?
I don't know what Simon and Tom will say, but I was cheekily just using
the directory, ignoring the current DM_SPL preference for code in
there. For the D1/T113s code this is probably a no-brainer, but
I also found it a nice and simple solution to declutter and cleanup
arch/arm/mach-sunxi and its Kconfig.
So yeah, it's just moving the files and Kconfig stanzas there, and
otherwise leaves the actual code untouched. We still call
sunxi_dram_init() from our legacy SPL code.
Cheers,
Andre
>
> Best regards,
> Jernej
>
> >
> > Cheers,
> > Andre
> >
> > > Please take a look.
> > >
> > > Best regards,
> > > Jernej
> > >
> > > Jernej Skrabec (8):
> > > sunxi: Fix write to H616 DRAM CR register
> > > sunxi: cosmetic: Fix H616 DRAM driver code style
> > > sunxi: parameterize H616 DRAM ODT values
> > > sunxi: Convert H616 DRAM options to single setting
> > > sunxi: Always configure ODT on H616 DRAM
> > > sunxi: Make bit delay function in H616 DRAM code void
> > > sunxi: Parameterize bit delay code in H616 DRAM driver
> > > sunxi: Parameterize H616 DRAM code some more
> > >
> > > .../include/asm/arch-sunxi/dram_sun50i_h616.h | 18 +
> > > arch/arm/mach-sunxi/Kconfig | 67 +--
> > > arch/arm/mach-sunxi/dram_sun50i_h616.c | 445 +++++++++++-------
> > > configs/orangepi_zero2_defconfig | 8 +-
> > > 4 files changed, 348 insertions(+), 190 deletions(-)
>
>
>
>
prev parent reply other threads:[~2023-01-04 23:23 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-11 16:32 [PATCH 0/8] sunxi: Update H616 DRAM driver Jernej Skrabec
2022-12-11 16:32 ` [PATCH 1/8] sunxi: Fix write to H616 DRAM CR register Jernej Skrabec
2023-01-04 0:35 ` Andre Przywara
2022-12-11 16:32 ` [PATCH 2/8] sunxi: cosmetic: Fix H616 DRAM driver code style Jernej Skrabec
2023-01-04 0:36 ` Andre Przywara
2022-12-11 16:32 ` [PATCH 3/8] sunxi: parameterize H616 DRAM ODT values Jernej Skrabec
2023-01-04 0:36 ` Andre Przywara
2022-12-11 16:32 ` [PATCH 4/8] sunxi: Convert H616 DRAM options to single setting Jernej Skrabec
2022-12-12 17:50 ` Andre Przywara
2022-12-13 16:23 ` Jernej Škrabec
2022-12-13 16:51 ` Andre Przywara
2022-12-13 17:08 ` Jernej Škrabec
2022-12-11 16:32 ` [PATCH 5/8] sunxi: Always configure ODT on H616 DRAM Jernej Skrabec
2023-01-04 0:37 ` Andre Przywara
2023-01-04 21:12 ` Jernej Škrabec
2022-12-11 16:32 ` [PATCH 6/8] sunxi: Make bit delay function in H616 DRAM code void Jernej Skrabec
2023-01-04 0:37 ` Andre Przywara
2022-12-11 16:32 ` [PATCH 7/8] sunxi: Parameterize bit delay code in H616 DRAM driver Jernej Skrabec
2023-01-04 0:37 ` Andre Przywara
2023-01-04 21:28 ` Jernej Škrabec
2022-12-11 16:32 ` [PATCH 8/8] sunxi: Parameterize H616 DRAM code some more Jernej Skrabec
2022-12-11 18:33 ` Jernej Škrabec
2023-01-04 0:38 ` Andre Przywara
2023-01-04 21:30 ` Jernej Škrabec
2022-12-12 1:04 ` [PATCH 0/8] sunxi: Update H616 DRAM driver Andre Przywara
2022-12-12 16:14 ` Jernej Škrabec
2023-01-04 0:47 ` Andre Przywara
2023-01-04 21:02 ` Jernej Škrabec
2023-01-04 23:21 ` Andre Przywara [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230104232148.5456b4ba@slackpad.lan \
--to=andre.przywara@arm.com \
--cc=jagan@amarulasolutions.com \
--cc=jernej.skrabec@gmail.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.