Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 03 9月, 2014 5 次提交
  3. 27 7月, 2014 1 次提交
  5. 26 7月, 2014 2 次提交
  7. 24 7月, 2014 2 次提交
    • D
      [media] rc-core: document the protocol type · 120703f9
      由 David Härdeman 提交于 
      Right now the protocol information is not preserved, rc-core gets handed a
scancode but has no idea which protocol it corresponds to.

This patch (which required reading through the source/keymap for all drivers,
not fun) makes the protocol information explicit which is important
documentation and makes it easier to e.g. support multiple protocols with one
decoder (think rc5 and rc-streamzap). The information isn't used yet so there
should be no functional changes.

[m.chehab@samsung.com: rebased, added cxusb and removed bad whitespacing]
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      120703f9
    • D
      [media] dib0700: NEC scancode cleanup · af3a4a9b
      由 David Härdeman 提交于 
      the RC RX packet is defined as:

        struct dib0700_rc_response {
		...
                                u8 not_system;
                                u8 system;
		...
                u8 data;
                u8 not_data;

The NEC protocol transmits in the order:
        system
        not_system
        data
        not_data

Note that the code defines the NEC extended scancode as:

        scancode = be16_to_cpu(poll_reply->system16) << 8 | poll_reply->data;

i.e.

        scancode = poll_reply->not_system << 16 |
                   poll_reply->system     << 8  |
                   poll_reply->data;

Which, if the order *is* reversed, would mean that the scancode that
gets defined is in reality:

        scancode = poll_reply->system     << 16 |
                   poll_reply->not_system << 8  |
                   poll_reply->data;

Which is the same as the order used in drivers/media/rc/ir-nec-decoder.c.

This patch changes the code to match my assumption (the generated scancode
should, however, not change).

[m.chehab@samsung.com: rebased and fixed the decoding error message]
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
CC: Patrick Boettcher <pboettcher@kernellabs.com>
Tested-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      af3a4a9b
  9. 23 7月, 2014 1 次提交
  11. 22 7月, 2014 2 次提交
  13. 15 7月, 2014 1 次提交
  15. 07 7月, 2014 1 次提交
  17. 26 6月, 2014 1 次提交
  19. 17 6月, 2014 4 次提交
    • M
      [media] dib8000: export just one symbol · d44913c1
      由 Mauro Carvalho Chehab 提交于 
      Exporting multiple symbols don't work as it causes compilation
breakages, due to the way dvb_attach() works.

The bug happens when:
        CONFIG_DVB_DIB8000=m
	CONFIG_DVB_USB_DIB0700=y

As a bonus, dib8000 won't be loaded anymore if the device uses
a different frontend, reducing the memory footprint.

Tested with both Pixelview PV-D231 and MyGica S870.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      d44913c1
    • M
      [media] dib8000: rename dib8000_attach to dib8000_init · b9bc7d59
      由 Mauro Carvalho Chehab 提交于 
      Well, what we call as "foo_attach" is the method that should
be called by the dvb_attach() macro.

It should be noticed that the name "dvb_attach" is really a
bad name and don't express what it does.

dvb_attach() basically does three things, if the frontend is
compiled as a module:
- It lookups for the module that it is known to have the
  given symbol name and requests such module;
- It increments the module usage (anonymously - so lsmod
  doesn't print who loaded the module);
- after loading the module, it runs the function associated
  with the dynamic symbol.

When compiled as builtin, it just calls the function given to it.

As dvb_attach() increments refcount, it can't be (easily)
called more than once for the same module, or the kernel
will deny to remove the module, because refcount will never
be zeroed.

In other words, the function name given to dvb_attach()
should be one single symbol that will always be called
before any other function on that module to be used.

For almost all DVB frontends, there's just one function,
but, on dib8000, there are several exported symbols.

We need to get rid of all those direct calls, because they
cause compilation breakages when bridge is builtin and
frontend is module, we'll need to add a new function that
will be the first one to be called, whatever initialization
is needed.

So, let's rename this function, in order to prepare for
a next patch that will add a new attach() function that
will be the only one exported by this module.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      b9bc7d59
    • M
      [media] dib7000: export just one symbol · 8abe4a0a
      由 Mauro Carvalho Chehab 提交于 
      Exporting multiple symbols don't work as it causes compilation
breakages, due to the way dvb_attach() works.

This were reported several times, like:

   drivers/built-in.o: In function `cxusb_dualdig4_rev2_tuner_attach':
>> cxusb.c:(.text+0x27d4b5): undefined reference to `dib7000p_get_i2c_master'
   drivers/built-in.o: In function `dib7070_set_param_override':
   cxusb.c:(.text+0x27d5a5): undefined reference to `dib0070_wbd_offset'
>> cxusb.c:(.text+0x27d5be): undefined reference to `dib7000p_set_wbd_ref'
   drivers/built-in.o: In function `dib7070_tuner_reset':
>> cxusb.c:(.text+0x27d5f9): undefined reference to `dib7000p_set_gpio'
   drivers/built-in.o: In function `cxusb_dualdig4_rev2_frontend_attach':
>> cxusb.c:(.text+0x27df5c): undefined reference to `dib7000p_i2c_enumeration'

In this specific report:
	CONFIG_DVB_USB_CXUSB=y
	CONFIG_DVB_DIB7000P=m

But the same type of bug can happen if:
	CONFIG_DVB_DIB7000P=m
and one of the bridge drivers is compiled builtin (cxusb, cx23885-dvb
and/or dib0700).

As a bonus, dib7000p won't be loaded anymore if the device uses
a different frontend, reducing the memory footprint.

Tested with Hauppauge Nova-TD (2 frontends).
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      8abe4a0a
    • M
      [media] dib7000p: rename dib7000p_attach to dib7000p_init · 7f67d96a
      由 Mauro Carvalho Chehab 提交于 
      Well, what we call as "foo_attach" is the method that should
be called by the dvb_attach() macro.

It should be noticed that the name "dvb_attach" is really a
bad name and don't express what it does.

dvb_attach() basically does three things, if the frontend is
compiled as a module:
- It lookups for the module that it is known to have the
  given symbol name and requests such module;
- It increments the module usage (anonymously - so lsmod
  doesn't print who loaded the module);
- after loading the module, it runs the function associated
  with the dynamic symbol.

When compiled as builtin, it just calls the function given to it.

As dvb_attach() increments refcount, it can't be (easily)
called more than once for the same module, or the kernel
will deny to remove the module, because refcount will never
be zeroed.

In other words, the function name given to dvb_attach()
should be one single symbol that will always be called
before any other function on that module to be used.

For almost all DVB frontends, there's just one function.

However, the dib7000p initialization can require up to 3
functions to be called:
	- dib7000p_get_i2c_master;
	- dib7000p_i2c_enumeration;
	- dib7000p_init (before this patch dib7000_attach).

(plus a bunch of other functions that the bridge driver will
need to call).

As we need to get rid of all those direct calls, because they
cause compilation breakages when bridge is builtin and
frontend is module, we'll need to add a new function that
will be the first one to be called, whatever initialization
is needed.

So, let's rename the function that probes and init the hardware
to dib7000p_init.

A latter patch will add a new dib7000p_attach that will be
used as originally conceived by dvb_attach() way.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      7f67d96a
  21. 26 5月, 2014 2 次提交
    • M
      [media] dib0700: fix RC support on Hauppauge Nova-TD · c4018fa2
      由 Mauro Carvalho Chehab 提交于 
      The RC support o Nova-TD is broken, as the RC endpoint there
is an interrupt endpoint.

That produces an ugly calltrace at the Kernel logs:

	WARNING: CPU: 2 PID: 56 at drivers/usb/core/urb.c:450 usb_submit_urb+0x1fd/0x5c0()
	usb 1-1.2: BOGUS urb xfer, pipe 3 != type 1
	Modules linked in: rc_dib0700_rc5(OF) dvb_usb_dib0700(OF) dib9000(OF) dib8000(OF) dib7000m(OF) dib0090(OF) dib0070(OF) dib7000p(OF) dib3000mc(OF) dibx000_common(OF) dvb_usb(OF) rc_core(OF) snd_usb_audio snd_usbmidi_lib snd_hwdep snd_rawmidi snd_seq snd_seq_device snd_pcm snd_timer snd soundcore bnep bluetooth 6lowpan_iphc rfkill au0828(OF) xc5000(OF) au8522_dig(OF) au8522_common(OF) tveeprom(OF) dvb_core(OF) nouveau i915 mxm_wmi ttm i2c_algo_bit drm_kms_helper drm r8169 mii i2c_core video wmi [last unloaded: au0828]
	CPU: 2 PID: 56 Comm: khubd Tainted: GF          O 3.14.2-200.fc20.x86_64 #1
	Hardware name: SAMSUNG ELECTRONICS CO., LTD. 550P5C/550P7C/SAMSUNG_NP1234567890, BIOS P05ABI.016.130917.dg 09/17/2013
	 0000000000000000 00000000610866bc ffff880223703860 ffffffff816eec92
	 ffff8802237038a8 ffff880223703898 ffffffff8108a1bd ffff8800916a2180
	 ffff8801d5b16000 0000000000000003 0000000000000003 0000000000000020
	Call Trace:
	 [<ffffffff816eec92>] dump_stack+0x45/0x56
	 [<ffffffff8108a1bd>] warn_slowpath_common+0x7d/0xa0
	 [<ffffffff8108a23c>] warn_slowpath_fmt+0x5c/0x80
	 [<ffffffff814e3ebd>] usb_submit_urb+0x1fd/0x5c0
	 [<ffffffffa0445925>] dib0700_rc_setup+0xb5/0x120 [dvb_usb_dib0700]
	 [<ffffffffa0445a58>] dib0700_probe+0xc8/0x130 [dvb_usb_dib0700]
	...

Fix it by detecting if the endpoint is bulk or interrupt.

Tested with both Hauppauge Nova-TD model 52009 (interrupt) and with a
		 Prolink Pixelview SBTVD model PV-D231U (bulk).
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      c4018fa2
    • M
      [media] az6027: Added the PID for a new revision of the Elgato EyeTV Sat DVB-S Tuner · 44f83144
      由 Manuel Schönlaub 提交于 
      There is another clone of AZ6027. This patch adds the relevant PID.
Signed-off-by: NManuel Schönlaub <manuel.schoenlaub@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      44f83144
  23. 24 5月, 2014 1 次提交
  25. 12 3月, 2014 1 次提交
  27. 11 12月, 2013 4 次提交
  29. 29 11月, 2013 1 次提交
  31. 08 11月, 2013 3 次提交
  33. 17 10月, 2013 1 次提交
  35. 02 10月, 2013 1 次提交
    • J
      [media] media: dvb-frontends: ts2020: Added in a option for frequency divider... · 03a67279
      由 John Horan 提交于 
      [media] media: dvb-frontends: ts2020: Added in a option for frequency divider value for s600 devices

When the tuner part of the ds3000 driver was split to share code with the m88rs2000 driver, the ts2020 driver used
the frequency divider value from the m88rs2000 driver.  However the ds3000 driver requires a different value, and this
resulted in some frequecies being invisible to the tuner.  This patch adds back in the value needed for the ds3000 driver
and configured as an option in the dw2102 frontend driver.
It may also apply to su3000 devices, which use the same ds3000 driver, but for now it is only applied to the s660 device.
Signed-off-by: NJohn Horan <knasher@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      03a67279
  37. 31 7月, 2013 1 次提交
  39. 22 7月, 2013 1 次提交
  41. 21 5月, 2013 1 次提交
  43. 23 4月, 2013 3 次提交