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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox