[U-Boot] [PATCH 3/4] pci: mediatek: Add pci-driver for mt2701

[Ryder Lee <ryder.lee@mediatek.com>]

On Wed, 2019-07-31 at 18:09 +0200, Frank Wunderlich wrote:
> Hi Ryder,
> 
> you know that we cannot write a full, multi-device driver here :)

Just need to write mt7623 part. And what I'm saying is you have a
perfect dts with many phandles listed there. (i.e. clk, reset, reg and
phy) https://patchwork.ozlabs.org/patch/1139695/
However the patch directly puts everything into PCI driver without using
other modules. We should switch to use them.

> > Gesendet: Mittwoch, 31. Juli 2019 um 17:23 Uhr
> > Von: "Ryder Lee" <ryder.lee@mediatek.com>
> > > imho we can use single driver for different IP generation and that is
> > > what we did in linux now.
> > >
> > > MT7623/MT2701 - mtk_pcie_soc_v1
> > > MT7622/MT7629 - v2
> > > gen3 IP - TBD
> 
> i ack that's the right way, but this cannot be done by people outside (that do not have knowledge about multiple chips the driver should cover) and not only in freetime, so our approach was to create a driver for this chip (that is also used by other soc) as base for future developement (extending for other boards).
> 
> on any time it needs to be replaced by a more universal variant to have not the same code multiple times. but thats far away from we can do here
> 
> it's not the best code (based on magic values and portability to other devices), but from my point of view we have working sata and do not modify existing code too much (to avoid side-effects), but only figuring out which consts are used in linux take much time for us
> 
> > > phy driver is used for configuring basic settings, there is no complex
> > > logic in it. we can even copy and paste the entire block from that
> > > driver.
> you know the technical details :)
> what we do is read out registers in linux and try to adapt this in uboot ;) because drivercode itself is too big for us to understand
> 
> > > .version = MTK_PHY_V1
> > > case PHY_TYPE_PCIE:
> > > 	pcie_phy_instance_init(tphy, instance);
> > More specifically, we should use pci_generic_mmap_write/read_config()
> > for standard set of confi read/write operations so that we can get rid
> > of the helpers here.
> 
> a general way is right, but not possible to created by people not working for mtk :) without the right documentation
> we do not have the knowledge to port a driver like this from linux to uboot
> > I think the uboot driver end up dealing with nothing but just doing some
> > initial parts (< 300 lines I guess), or you can take pcie_xilinx or
> > pci_tegra as examples.
> > > we can directly replace these chunks with mtk_pcie_startup_port()
> > > (pcie-mediatek.c) and there are many defines for the registers/bit
> > > field.
> 
> i tried this, but just C&P does not work ( i'm not that naive :) ) because of many depencies (functions used in linux-variant), i have already changed some things, but it ended in needed touching corefiles of uboot (e.g. extending pci.h) which may break other drivers.
> 
> but at least i have this version (with some fix-ups you've mentioned here) on my github-repo so that everybody can use it for my board/other boards using mt2701
> 
> https://github.com/frank-w/u-boot/commits/2019-07-bpi-r2-sata_new (will merge that in other main branches till official driver is there)
> 
> regards Frank

The document has been opened in the air -
https://drive.google.com/file/d/0B_YnvHgh2rwjR3pwSzNrS1Nqdjg/view?usp=sharing
or google 'MTK 7623N datasheet for development board programming guide'.
or just look at Linux driver to know the defines.

But do you really need these stuff? Since the HW settings are fixed
there unless you want to fine-tune something. I think we just need to
understand how core layer works and how to add the hook points.

IMHO What we should do for opensource driver is keep code quality and
maintainability, modularity thus improves readability through a
well-organized design and build state machines in our head of what the
code is doing. This meant that when we have a problem, we could easily
scrub through all the code that our functionality depended on
(modularity), trace the problem, and eventually optimize the code
(maintainability) - it all helps everything move forward.. 

Anyway I wrote a quick patch for PCIe this morning but didn't test it
yet (and I'm a careless guy). I think maybe you can try it out and do
some proper modifications according your test.
https://pastebin.com/kyTqEBJf

Also we need to add a PHY driver support for it :)

Ryder