1. 07 7月, 2014 1 次提交
  2. 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
  3. 26 5月, 2014 1 次提交
    • 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
  4. 22 7月, 2013 1 次提交
  5. 23 4月, 2013 4 次提交
  6. 27 10月, 2012 1 次提交
    • D
      [media] rc-core: add separate defines for protocol bitmaps and numbers · c003ab1b
      David Härdeman 提交于
      The RC_TYPE_* defines are currently used both where a single protocol is
      expected and where a bitmap of protocols is expected.
      
      Functions like rc_keydown() and functions which add/remove entries to the
      keytable want a single protocol. Future userspace APIs would also
      benefit from numeric protocols (rather than bitmap ones). Keytables are
      smaller if they can use a small(ish) integer rather than a bitmap.
      
      Other functions or struct members (e.g. allowed_protos,
      enabled_protocols, etc) accept multiple protocols and need a bitmap.
      
      Using different types reduces the risk of programmer error. Using a
      protocol enum whereever possible also makes for a more future-proof
      user-space API as we don't need to worry about a sufficient number of
      bits being available (e.g. in structs used for ioctl() calls).
      
      The use of both a number and a corresponding bit is dalso one in e.g.
      the input subsystem as well (see all the references to set/clear bit when
      changing keytables for example).
      
      This patch separate the different usages in preparation for
      upcoming patches.
      
      Where a single protocol is expected, enum rc_type is used; where one or more
      protocol(s) are expected, something like u64 is used.
      
      The patch has been rewritten so that the format of the sysfs "protocols"
      file is no longer altered (at the loss of some detail). The file itself
      should probably be deprecated in the future though.
      Signed-off-by: NDavid Härdeman <david@hardeman.nu>
      Cc: Andy Walls <awalls@md.metrocast.net>
      Cc: Maxim Levitsky <maximlevitsky@gmail.com>
      Cc: Antti Palosaari <crope@iki.fi>
      Cc: Mike Isely <isely@pobox.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      c003ab1b
  7. 14 8月, 2012 1 次提交
  8. 20 4月, 2012 1 次提交
  9. 18 1月, 2012 4 次提交
  10. 31 12月, 2011 2 次提交
  11. 25 11月, 2011 7 次提交
  12. 21 9月, 2011 4 次提交
  13. 07 9月, 2011 1 次提交
  14. 31 7月, 2011 1 次提交
  15. 28 7月, 2011 7 次提交