search

PabloPL / linux

Linux kernel source tree
Other
17 stars 0 forks source link

onenand support #31

Open xc-racer99 opened 5 years ago

xc-racer99 commented 5 years ago

In addition to the DT patches floating around (on for-upstream/onenand), there's still some subpage sft/oob layout differences that I will try to explain. Additionally there are the 8Gb changes for SGS4G devices

99b17c08bca2810f5910b3027f1b9d82edf7a576 swapped out the oob layout and subpage sft. This was found to have some issues (described in https://patchwork.ozlabs.org/patch/98355/ - there is even mention of Nexus S here) how different versions had slight differences. The above conversation resulted in e1c10243df92822954b9b5e04d12dd2f23a39652 - but I have no idea how the oob layout changes may affect things (v1 discussion for above patch is at https://patchwork.ozlabs.org/patch/99352/ v2 discussion at https://patchwork.ozlabs.org/patch/101392/).

Assuming it is only the subpage_sft that needs changing and that the new ooblayouts can be used, then the 8Gb patches should be adjusted to use ONENAND_HAS_NOP_1 - I will try and test this and see if it's possible.

xc-racer99 commented 5 years ago

Have confirmed that e1c10243df92822954b9b5e04d12dd2f23a39652 (already upstream) should allow things to work on the i9000 on mainline - as switching up the 8Gb support to add the ONENAND_HAS_NOP_1 option still allows things to work just fine.

As such, I've updated the 8Gb patch on for-upstream/onenand to use this method as it is cleaner.

I think that the onenand patches are now ready to be sent to upstream sometime or another.

PabloPL commented 5 years ago

Ok, i think i'll send onenand patches in 3 parts:

xc-racer99 commented 5 years ago

for-upstream/onenand has patches updated (but still based on 5.1-rc6) after review from upstream: Changes from v1:

Additionally, in the first review, it was suggested to split the first patch (unify resource order for controller variants) in two due to the renaming of fields in the main onenand structure. However, it is only fields in the private s3c_onenand structure that are being renamed so it has been left as one patch.

@PabloPL if you want to have a quick look over them, rebase them on a newer upstream, and resubmit them that would be great. If you could also resend the 8Gb datasize OneNAND that would be appreciated.

PabloPL commented 5 years ago

Branch rebased on current upstream.

PabloPL commented 5 years ago

FYI 8Gb datasize OneNAND patch was accepted in upstream

Edit 1: Merged into upstream

PabloPL commented 5 years ago

I'm going to split "unify resource order for controller variants" patch like they suggested and send whole onenand to upstream.

xc-racer99 commented 5 years ago

FYI don't try and merge this upstream yet. It appears I'm having some issues with this patchset as is that I thought was an upstream problem but turns out that it isn't...

xc-racer99 commented 5 years ago

Ok, figured out the issue. For DT case I had missed setting phys_base which is used during DMA transfer. Hence everything probed correctly but reading/writing data was broken.

Branch force-pushed with updated patches.