linux
linux copied to clipboard
PabloPL
onenand support
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.
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.
Ok, i think i'll send onenand patches in 3 parts:
- first which adds device tree support
- patch which adds 8Gb datasize onenand can be send separate (need to edit commit message)
- patches which enables onenand for aries can be send as part of Aries patches v3
for-upstream/onenand has patches updated (but still based on 5.1-rc6) after review from upstream: Changes from v1:
- Reviewed-by tags added
- Split into separate controller/chip nodes
- Remove implied interrupt-parent entry
- Remove s5pc100 binding as the driver has had s5pc100 support removed
- Added another patch that removes some dead code
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.
FYI 8Gb datasize OneNAND patch was accepted in upstream
Edit 1: Merged into upstream
I'm going to split "unify resource order for controller variants" patch like they suggested and send whole onenand to upstream.
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...
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.