User Details
- User Since
- Feb 3 2015, 4:54 AM (435 w, 5 h)
Tue, May 9
I strongly disagree, it's a clear step backwards. Intrng was designed with strong layer separation and you are trying to break it in a similar way to x86.
The consumer interface for interrupts is in the kern_intr.c file and no one else is allowed to use it. The provider interface is intr_isrc_*. All other functions should (and must) remain private or unpublished outside of intrng.
Apr 27 2023
Apr 26 2023
More than enough, thanks. And sorry for starting this in the wrong review.
Apr 24 2023
I see. So in this case can we enable swp emulation using sysctl, disabled by default? I'm worried that this may cause bad behavior for ports build for arm32 - the port may detect swp during build. A bit paranoid, I know.
Apr 21 2023
Hmm, the SWP/SWPB instruction is obsolete in ARMv7 ISA (in favor of atomic operations). It not supported/implemented on ARMv7 SMP cpus and arm32 kernel doesn't support it at all. IMHO we should be consistent at least between arm32 and compat32 on aarch64.
Mar 26 2023
Mar 22 2023
fyi, original idea was provide (not-preferred) way how to (limited) boot FreeBSD on a board with a problematic u-boot that might be locked or need lots of GPL or Linux specific utilities. It was easy for arm64 (where any u-boot can handle a booti image that is generic and has an easy format), but it's hard for armv7, where bootm needs an external program and the resulting image is not generic - it has a built-in load and boot address.
from my current point of view something like user submake stubs will be better (in simple words - be may include and run user definable makefile fragment) -> so system make can try to run this fragment for postprocessing
Feb 11 2023
I like that a lot, I'd do it anyway, thanks. .
Jan 17 2023
IMHO NEW_PCIB is an essential feature for all arm/arm64 FDT based boards. Or more generally, it is essential for all boards where the bootloader/firmware does not fully initialize all PCI hardware, i.e. all systems without ACPI.
Jan 3 2023
Nov 14 2022
I don't think this feature is appropriate for a generic layer. Practically no physical clock can implement it. A PLL can typically produce trillions of discrete frequencies, which makes it practically impossible to enumerate.
Oct 29 2022
Oct 28 2022
Thanks .
Oct 27 2022
Oct 2 2022
Isn't that a bit (I don't want to say too much) excessive? All that's needed is to teach sysctl about skipping deleted (empty) intrnames, and to add topology sx lock to deliver a consistent view into user space (plus an allocator for free intrnames item in isrc->isrc_index). I'm almost certain that this big unnecessary change is uncommittable.
I see a misunderstanding here.
INTR_SOLO have nothing to do with shared interrupts. It's a fast path for cascading interrupts, and instead of removing it, we should extend it to support pass-through interrupts, polish the API for it, and put it in the regular build. Both of these are common in the arm/aarch64 world, and we lose performance significantly in these cases (and the big question is whether this should help us for LPI interrupts as well).
Jul 30 2022
I don't have a single problem with intr_irq_root_dev partitioning. I feel that this implementation (priority based selection) is probably not viable in the long term and it seems to be RISC-V specific (i.e. not suitable for a platform independent framework). But decoupling the IPI controller from the root controller will allow us to do it all in a platform-specific "virtual" layer, so I don't went block you. But I have a slight problem with keeping the fallback IPI functionality in the root interrupt controller. We actually only have a few root controllers in the codebase, so adding a one-line intr_ipi_pic_register() function to all of them is not a big deal, which an reduce future bloating of spaghettis like functionally. What do you think?
Jul 16 2022
Perfect, many thanks for cooperation.
Jul 10 2022
I'm so sorry, but NACK.
This is the wrong way. A thermal sensor is not a thermal zone - > one sensor can be part of multiple zones, and one zone can consist of multiple sensors. The zone is a property of the board/case, while the sensor is (mostly) a property of the SOC. We should not mix them.
Moreover an in this case, since the sensors are located on the SoC, there is no reason why we should not hardcode its name (and number of sensors) directly in the driver.
Jul 4 2022
Jul 3 2022
That's fine with me, thank you.
Only minor nit.
Is necessary to shadow HWPARAMS? Shadowing the HW registry is always a pain and a source of confusion and errors. IMHO it should only be used as a last resort...
Jul 1 2022
And why didn't you leave it enabled? IMHO all HWACCEL blocks look the same, so the risk of a possible error is minimal.
How is '#ifdef HWACCEL3' compatible with the generic kernel and why do we need it at all?
Jun 16 2022
Jun 9 2022
It solved my problem and it boots without any problems on all my arm64 boards. Thanks.
Jun 8 2022
Feb 25 2022
ping
Feb 23 2022
Feb 22 2022
Yes, I mean we end up in kobj_error_method. And that's a very real scenario. In newbus, the default method is only applied for the given class and its subclasses. *Not for all classes*
Unfortunately, it looks bad.
Up until SDHCI v3.0, SDMA is strictly 32-bit, only ADMA mode (which we don't support yet, it is optionally 64-bit). As you can see at https://cgit.freebsd.org/src/tree/sys/dev/sdhci/sdhci.c#n1977, the driver ends up writing only the 32-part of buffer physical address to the DMA base register.
Just a very minor notice . Wouldn't it be better to name the VM memory attribute by function, not by type? Different architectures may have different attribute mapping requirements for the PCI configuration space, and something like a global VM_MEMATTR_PCI_CONFIG (may be aliased to platform specific VM_MEMATTR_DEVICE_NP on arm64) gives us a much better chance of having cross-platform drivers without #ifdef hell.
Feb 21 2022
Ahh right, thanks.
There is also a tegra pcie driver that is common to arm and arm64 , so we should define VM_MEMATTR_DEVICE_NP for arm as well. But I'm not sure if we have the rest of the necessary infrastructure implemented on arm.
Feb 20 2022
Feb 18 2022
I see and I think that original implementation was more correct.
I don't think that's right. We can't expect that all indirect descendants of simplebus were instantiated by simplebus. Typically all enumerable buses (e.g. pci or multifunction devices represented by single FDT node) are not derived from simplebus. You cannot use ofw_bus_get_node(child) on those.
IMHO we can have a single generic implementation of <foo>_get_property for a given bus , but it should be explicitly defined in the device_methods structure for all appropriate drives.
Feb 14 2022
Yes, I've applied all the patches. The problem is that the HS SD card (i.e. without debugging) also doesn't work and I don't know why.
Due to problems with the D32706 I can't verify this on Honeycomb, plus I've never been able to have a working HW tuning. The current state is that this whole series of patches leaves Honeycomb with a non-functioning SD and eMMC. I currently have almost no free time to hack this problem, so everything is taking forever, sorry :(
Feb 7 2022
First of all, I apologize for being too harsh.
The problem is that this patch breaks both SD and eMMC on Honeycomb (LX2160). the eMMC is not detected at all, abd HSSSD card fires out with tons of CRC errors.
Unfortunately however this patch break SD and eMMC on Honezcomb (LX2160).
After further digging, I thing that fsl_sdhc_fdt_set_clock() is broken from day zero.
fsl_sdhc_fdt_set_clock() was supposed to be paired with fsl_sdhc_fdt_get_clock() to perform a conversion of differences between SDHCI and eSDHCl clock register format.
Feb 5 2022
Unfortunately this does not work at all and should be reverted.
eSDHC implements two versions of the clock divider, which are selected by the ESDHCCTL[CRS] bit.
Jan 31 2022
Jan 20 2022
Jan 10 2022
Jan 6 2022
Dec 30 2021
Tried and tested - it fixes my previous problem, thanks.
Dec 27 2021
You know I'm "creative", especially when it comes to booting SBC.
The failing sequence is:
Dec 26 2021
Dec 25 2021
Unfortunately thiss broke tftp kernel loading.
The tftp_open() function will prefetch the first block and leave tftpfile->currblock set to 1, so the first block is never loaded into the cache.
The trivial fix is to reset it back to 0, it works for me but I'm not sure if that's the right solution.
Dec 24 2021
Dec 23 2021
Sorry for the strong language, please don't take it the wrong way.
clknode_init_freq_value() - this function is completely unnecessary, and only complicates an already complicated interface. Moreover, it is only used here as papering over a real problem in sysctl dump code. Ii really don't want that.
Dec 10 2021
Dec 9 2021
ofw_bus_node_is_compatible(OF_finddevice("/"), "fsl,lx2160a")
does the trick (assuming that OF_finddevice("/") cannot fail)...
This breaks mmc on FDT based Honeycomb with following log:
I see. But why you cannot use something like this (tested only on Honecomb) https://github.com/strejda/freebsd/commit/40eb737b2e9ca485daef8bf2effa96b053f847f9 ? Advantage of this code is that it can stay unchanged after thermal-zone driver was introduced..
I see. But why can't you use something like this (tested only on Honeycomb) https://github.com/strejda/freebsd/commit/40eb737b2e9ca485daef8bf2effa96b053f847f9 ? The advantage of this code is that it can remain unchanged after the thermal zone driver has been introduced.
LGTM
Dec 8 2021
Sorry, I didn't realize we were talking about a different SoC.
For me, the only relevant source on the number of sensors is TRM, not the DT files.
The current code is ready for variable number of sensors, just fill a new struct tsensor array according to TRM and use that instead of default_sensors. Unfortunately, due to a strange habit in QorIQ DT we have to use compatible string of the root node itself instead of the compatible string of the thermal controller :( . See comment on (original) line 311.
Where do you see the problem?
Dec 6 2021
I'm sorry, but I don't agree with this.
The temperature sensor is a different entity from a temperature zone which we can not mix. A given SOC always has a fixed number of temperature sensors but the number of temperature zones is determined by the design of the board/laptop/equipment. In addition, one temperature zone can be controlled by multiple temperature sensors (where each can have a different weight) and can control multiple cooling devices. A sensor may or may not be a member of a thermal zone and yet its value may be useful to the user (and thus accessible, for example, by sysctl(8)).
I have an initial implementation (almost ready to commit) of a temperature sensor framework and a very early implementation of thermal zones - both necessary for temperature controlled cooling. The problem is that I don't have the free time to finish them right now... So take what you want, or give me time over Christmas, I'll try to finish it to a committable state.
Dec 1 2021
Nov 2 2021
Thanks
Oct 18 2021
on ARM (and on other intrng enabled systems) the interrupt resource does not represent the real interrupt - it is an arbitrarily assigned index that points to opaque interrupt mapping data collected by ofwbus - so multiple different interrupt resources can identify one actual interrupt or similar.
Oct 8 2021
Oct 1 2021
I think adding more irregularity to an already ill-defined code behavior is not a good idea. Moreover, I think this is an obvious driver error - requesting a single segment for a buffer that can bounce is clear nonsense in which case the driver should allocate the buffer using bus_dmamem_alloc() or possibly pass the buffer aligned. Copying multiple pages back and forth doesn't sound like an optimal solution.