In D47831#1091595, @br wrote:

In D47831#1091588, @mhorne wrote:

I strongly think this should be a newbus device driver. Unless there is some urgent need that it should be set up at SI_SUB_CPU?

This driver needed before threadinit() otherwise tid_alloc() won't work. It is needed even all cache ways in ccache driver are disabled (however the way 0 is always enabled). May be it flushes other L1/L2/L3 caches I am not sure, but from I saw the freebsd could not use memory that was just allocated in tid_alloc() without a flush. So this should go anywhere before SI_SUB_INTRINSIC.

In D47831#1091588, @mhorne wrote:

I strongly think this should be a newbus device driver. Unless there is some urgent need that it should be set up at SI_SUB_CPU?

This driver needed before threadinit() otherwise tid_alloc() won't work. It is needed even all cache ways in ccache driver are disabled (however the way 0 is always enabled). May be it flushes other L1/L2/L3 caches I am not sure, but from I saw the freebsd could not use memory that was just allocated in tid_alloc() without a flush. So this should go anywhere but before SI_SUB_INTRINSIC.

Right, sorry:)

store both reg and bit in the hwreset *id

copyright and style(9)

extract paddr on each page assuming the range is not contiguous

In D47412#1088559, @dev_submerge.ch wrote:

Also I suspect the input signal levels to be backwards now, please report your findings. The recorded signal should be loudest for "-10dBV" and quietest with "LowGain".

On the Input front, I have inserted Shure SM7B into External card Input 1, and I barely hear myself in Audacity. Slighly more loud on LowGain compare to +4dBu, but still very low on both. I could not set -10dBV because of off-by-one error somewhere (I guess).

In D47412#1087403, @dev_submerge.ch wrote:

In D47412#1086254, @br wrote:

On the "-10dbV" problem I could suggest to rename this to "minus10dbv" (and "plus4dbu as well).

Now that I think of it, we also have negative integer values in sysctl. Given that, it should be acceptable to use "-10dBV". It is quite a bit more readable and closer to RME / standard signal level terminology.

Could you please try to set "-10dBV" in a su -l session, to check whether this is a sudo problem? I read through the code again and didn't find any possible cause.

In D47688#1087747, @markj wrote:

In D47688#1087739, @jrtc27 wrote:

Perhaps worth mentioning in the commit message that RISC-V is unusual in allowing the TLB to cache invalid PTEs

I'm not sure that that's exactly what's happening - it might be that the core is caching translation structures (and this is certainly not specific to riscv) and requires a sfence.vma for PTE updates to be visible.

In fact, we might still want to issue a local sfence.vma when overwriting an invalid PTE in pmap_enter(), to avoid the overhead of spurious faults on first access. It's hard to say without some data on how common such faults are.

Works to me on SiFive Premier P550 (no hacky TLB flush needed anymore). Thanks!

On the "-10dbV" problem I could suggest to rename this to "minus10dbv" (and "plus4dbu as well).

(Note that default setting (-10dBV) is loudest, then +4dbU is lower, and HighGain is lowest volume)

Interesting, should be the other way round. The linux code doesn't seem to label these explicitly, which is why I expected the 0 value to be safe (quiet) similar to HDSP 9632. Chances are the input and output levels work the same and are in wrong order too, could you check them?

On travel currently -- will look next week.

Great work, thanks!

Regenerate

fix shift value of a register and remove bogus ones

unlock spin mutex when no interrupts found during APLIC CLAIM request

great idea, and happy to test (and actually use) if you can adopt to hdspe!

Regenerate

Instead of using static address for device tree blob, locate it just after bootrom image dynamically.

Address comments

Remove unrelated arm64/amd64 changes

Address markj@ comments, Thanks Mark

Regenerate

Regenerate

In D46409#1067830, @dev_submerge.ch wrote:

{F97460426}

This would be my proposed fix for the unified pcm device mode, plus some man page amendments.

@br, could you have a look and integrate this patch with yours if you agree with it? It's a git patch, apply with git am and then squash. Since I cannot test it without the hardware, could you please also try to enable the unified pcm mode?

In D46409#1063483, @dev_submerge.ch wrote:

In D46409#1062688, @br wrote:

I was just able to disconnect both extension cards on the fly when music was playing (without shutting down the PC), and then connected them back -- music still playing.
so hot swap may actually work

This means we can start a channel, set the start flag in the register, and the driver runs without the extension boards connected? Recording silence?
If that's the case we can keep the pcm device always present, no harm done.

I will write the HDSP equivalent and add the missing unified pcm device part there, for comparison. Hopefully this weekend.

handle VM_EXITCODE_SUSPENDED.
this fixes re-creation of a VM with the same name after graceful shutdown

In D46409#1062688, @br wrote:

In D46409#1062686, @br wrote:

In D46409#1060137, @br wrote:

In D46409#1059523, @dev_submerge.ch wrote:

But according to the manuals, the expansion board channels are always shown in the windows driver, so I think we can also keep "ext" pcm device always present. Could you please test that there's no harm in using the "ext" pcm device without any expansion boards? Is there an error or does it just run silently?

Let me check

I will check this on the first opportunity, I just don't want to loose work environment when rebooting as lots of windows are opened:)

I was just able to disconnect both extension cards on the fly when music was playing (without shutting down the PC), and then connected them back -- music still playing.
so hot swap may actually work

In D46409#1062686, @br wrote:

In D46409#1060137, @br wrote:

In D46409#1059523, @dev_submerge.ch wrote:

But according to the manuals, the expansion board channels are always shown in the windows driver, so I think we can also keep "ext" pcm device always present. Could you please test that there's no harm in using the "ext" pcm device without any expansion boards? Is there an error or does it just run silently?

Let me check

I will check this on the first opportunity, I just don't want to loose work environment when rebooting as lots of windows are opened:)

In D46409#1060137, @br wrote:

In D46409#1059523, @dev_submerge.ch wrote:

But according to the manuals, the expansion board channels are always shown in the windows driver, so I think we can also keep "ext" pcm device always present. Could you please test that there's no harm in using the "ext" pcm device without any expansion boards? Is there an error or does it just run silently?

Let me check

Regenerate

Move guest's hstatus bits initialization from vmmops_run() to vmmops_vcpu_init()

In D46409#1059523, @dev_submerge.ch wrote:

But according to the manuals, the expansion board channels are always shown in the windows driver, so I think we can also keep "ext" pcm device always present. Could you please test that there's no harm in using the "ext" pcm device without any expansion boards? Is there an error or does it just run silently?

reorder EXT channel between LINE and PHONE

Add a1 to the list of clobbers

remove htmp variable

Try to address issues discovered by jrtc27:

add vmexit_hyp for exceptions that could not be handled

Handle exceptions during unprivileged read using hlvx.hu

In D46409#1058233, @dev_submerge.ch wrote:

In D46409#1057745, @br wrote:

we actually need to change this patch to support stereo (I currently own just one studio monitor).
Should we do HDSPE_CHAN_AIO_EXT1 for two channels, and HDSPE_CHAN_AIO_EXT2 for another two channels? to support stereo.

The current state of the FreeBSD audio stack is that it's easy to split the channels of one pcm device into multiple pcm devices, using virtual_oss for example. In contrast there's almost no support for opening multiple pcm devices to combine them and use their channels in parallel.

Therefore, while two stereo pcm devices would be better than mono, I'd even prefer to combine all four channels into one pcm device for the extension boards. We can make it play / record mono on the first channel, or stereo on the first two channels, when the device is opened that way. The buffer_copy() implementation already handles such cases (for ADAT), I think we'd just have to include mono and stereo in the supported sound format capability list. Would that cover your use cases?

Another question, I didn't have time yet to study the linux code, are there flags in the registers to indicate the presence of the extension boards? They are not hot-swappable I suppose, so I think we shouldn't create those extra pcm devices when the extension boards are not present. I would probably also make a distinction between the AO4S and AI4S, and create separate pcm devices for them. As an option, we could do that as an improvement in a second step, and get it working for you in a "always present" mode first.

combine all external channels to a single channel

remove U_BOOT_SLAVE_PORTREVISION_2024.01= 1

Regenerate

sync with CURRENT: vmm_dev and vmm_stat moved to dev/vmm/

we actually need to change this patch to support stereo (I currently own just one studio monitor).
Should we do HDSPE_CHAN_AIO_EXT1 for two channels, and HDSPE_CHAN_AIO_EXT2 for another two channels? to support stereo.

Regenerate for Intel PT

Regenerate

Hi Himanshu what is status of this? could you regenerate for the latest HEAD ?