Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

WM8753 driver is not built for the Pi #1269

Closed
KevinStartup opened this issue Jan 27, 2016 · 7 comments
Closed

WM8753 driver is not built for the Pi #1269

KevinStartup opened this issue Jan 27, 2016 · 7 comments

Comments

@KevinStartup
Copy link

I am trying to get the WM8753 sound chip to work with the Pi over i2c but am unable to get the WM8753 to respond ove rthe i2c bus, despite it being registered at the address. I was directed here to ask for the WM8753 driver to be included in the kernel, can you help?
@Ruffio
Copy link

Ruffio commented Aug 17, 2016

@KevinStartup has your issue been resolved? If so, please close this issue. Thanks.

@KevinStartup
Copy link
Author

We have developed a custom i2c/i2s driver to support this chip. It is sort of working but needs more attention. As you can see, I received absolutely no help from this site whatsoever!

@clivem
Copy link

clivem commented Aug 18, 2016

@KevinStartup What exactly are you asking for? CONFIG_SND_SOC_WM8753=m to be added to default RPi configs, so the codec driver is built as module?

If you need help with the ASoC machine driver, show us the code you already have that 'is sort of working', and tell us what isn't actually working and people may be able to offer suggestions or help.

@KevinStartup
Copy link
Author

KevinStartup commented Aug 18, 2016 •
edited
Loading

@DigitalDreamtime
I guess what I'm suggesting is that all the CODECs that are actually included in the system are able to be loaded and configured into the kernel. CODECs exist for the wm8753 as well as lots of other sound chips but quite some work is required to get these working inside unix kernel with ASoC and ALSA. We've actually commissioned another company to cobble together a loader and configure the driver as a module within the kernel so that it can be loaded. Currently it works but falls over when ALSA is used in "memory mapped" mode which our sound software is utilising, hence it needs more work still. The details are complex and beyond my own capabilities, I can post the code that we're using here if anyone is interested but realistically to test it and work with it, you would need a Pi connected over i2c to a wm8753 chip.
I guess my overall suggestion here is to try to get a lot more sound-chip support into the Pi. It has the codecs available but getting them to work is difficult. This is one are where I think the Pi could be better developed. Windows supports pretty much any sound card you can think of nowadays but hardware support for the Pi is limited and complex. I just feel it would be nice to move towards an easier system to integrate the Pi with different audio and visual devices. We also have a custom LCD screen working with our Pi and that has been tricky, but at least easier to configure as only the device tree needs modification and a few lines in config.txt.
From a user point of view, it appears that half the work has been done to support a wide range of sound-chips and displays but the final user configuration is very tricky and requires specialist knowledge. I just personally think it's an area that could be improved.
If there is anyone that wishes to have the wm8753 development code and would like to have a look at it then please let me know and I can post it.
Cheerz
Kevin

@6by9
Copy link
Contributor

6by9 commented Aug 18, 2016

Have you tried connecting a WM8753 to Windows then? I'd be very surprised if there is any form of driver available, and I2S and I2C interfaces are not common on PCs anyway - USB, PCIe, or Firewire are preferred and much easier to handle. Except for USB, those interfaces are less common on SBCs.

Adding modules increases the size of the kernel distribution for everyone, and some modules will also have a performance penalty. That is why there is a general request to prove something works before the module will be built by default. Full instructions are available for you to be able to build your own kernel with a modified config, so it's not as if you're reliant on it being in the default build.

BTW Had you noticed https://www.cirrus.com/en/products/eol/detail/EOL421.html ?

WM8753
EOL Date: 7/31/2017

Building a new product on something that is going EOL in under a year may not be such a great plan. I haven't compared to the WM8750 and WM8758 that they're listing as replacements.

@KevinStartup
Copy link
Author

@6by9
Thanks for the EOL link, that is very useful, I've sent that on to those that decided to use this chip. It's primarily being used for backwards compatibility with our software to save us having to recode a lot of stuff as we use a lot of audio input and output from this chip which is all coded into our PCB and software application, so it was decided that we'd carry on using it rather than rejigging the PCBs and application software to cope (not my decision and for the record, I was against it, but that's another story)

I agree, I also think USB is the way forward and I accept your point that the wm8753 probably doesn't work on a PC and most other stuff over i2c won't work either! We've soldiered on with this at a great cost and only time will tell if it saves us work in the final PCB and application development but it looks like it might be time to buy up a job lot of the WM8753s for the coffers!

We looked at moving forwards to one of the newer chips, specifically the Cirrus Logic one loaded on their audio board (WM5102) but unfortunately the chip is too small to be put on by our manufacturing machinery so we had to go with the older one. That was a shame really as Cirrus have done all the work to get it configured on the Pi too.

I guess you're right, we can't expect to support every bit of hardware that exists and the mechanism is there to make it work - it's just really really hard! It was too hard for me anyway and we had to get someone with a bigger brain to have a go at it.

Thanks for getting involved though, it was nice at least to get a response. I'll close this thread to tidy up for Ruffio :)

Have a good night
Kevin

popcornmix pushed a commit that referenced this issue Dec 22, 2021
@borkmann
bpf, selftests: Update test case for atomic cmpxchg on r0 with pointer
e523102 
Fix up unprivileged test case results for 'Dest pointer in r0' verifier tests
given they now need to reject R0 containing a pointer value, and add a couple
of new related ones with 32bit cmpxchg as well.

  root@foo:~/bpf/tools/testing/selftests/bpf# ./test_verifier
  #0/u invalid and of negative number OK
  #0/p invalid and of negative number OK
  [...]
  #1268/p XDP pkt read, pkt_meta' <= pkt_data, bad access 1 OK
  #1269/p XDP pkt read, pkt_meta' <= pkt_data, bad access 2 OK
  #1270/p XDP pkt read, pkt_data <= pkt_meta', good access OK
  #1271/p XDP pkt read, pkt_data <= pkt_meta', bad access 1 OK
  #1272/p XDP pkt read, pkt_data <= pkt_meta', bad access 2 OK
  Summary: 1900 PASSED, 0 SKIPPED, 0 FAILED

Acked-by: Brendan Jackman <jackmanb@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
popcornmix pushed a commit that referenced this issue Dec 22, 2021
@borkmann @gregkh
bpf, selftests: Update test case for atomic cmpxchg on r0 with pointer
2746d3f 
commit e523102 upstream.

Fix up unprivileged test case results for 'Dest pointer in r0' verifier tests
given they now need to reject R0 containing a pointer value, and add a couple
of new related ones with 32bit cmpxchg as well.

  root@foo:~/bpf/tools/testing/selftests/bpf# ./test_verifier
  #0/u invalid and of negative number OK
  #0/p invalid and of negative number OK
  [...]
  #1268/p XDP pkt read, pkt_meta' <= pkt_data, bad access 1 OK
  #1269/p XDP pkt read, pkt_meta' <= pkt_data, bad access 2 OK
  #1270/p XDP pkt read, pkt_data <= pkt_meta', good access OK
  #1271/p XDP pkt read, pkt_data <= pkt_meta', bad access 1 OK
  #1272/p XDP pkt read, pkt_data <= pkt_meta', bad access 2 OK
  Summary: 1900 PASSED, 0 SKIPPED, 0 FAILED

Acked-by: Brendan Jackman <jackmanb@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@talksik
Copy link

talksik commented Aug 9, 2024

Thanks for this information. Helped me indirectly

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@clivem @Ruffio @6by9 @KevinStartup @talksik